Don’t get too comfortable – email authentication affects everyone

Things are not always as they seem. One day your emails are hitting their targets and everything is going brilliantly. The next you are scratching your head trying to work out what happened. All of a sudden email bounce is up and not as many emails are getting through. Must be the data right? WRONG.

fresh produce

If you think you know all about email marketing read on to learn about the complex and perplexing world of email authentication. You may have heard terms such as SPF, DKIM, Spoofing, DMARC – but what do they mean and how do they affect you?

Email bounces occur for a variety of reasons including data accuracy, security and authentication, email content, sending server, subject line and more. From our research we have found 50% of bounces can be attributed to data accuracy – the remaining 50% bounce for other reasons.

If your email marketing campaign reports regularly show a high number of bounces/failures, chances are the email servers at the receiving end aren’t even letting your emails through the gate because they think your emails look suspicious.

Without some form of proof in place at your end to show that your emails are, in fact, safe to deliver, they might not even make it to the recipient’s spam box, let alone their inbox. This type of email authentication is becoming more and more mainstream and should not be ignored.

Email authentication is a technical solution to proving that an email is not forged. In other words, it provides a way to verify that an email comes from who it claims to be from. Email authentication is most often used to block harmful or fraudulent uses of email such as phishing and spam.

The “proof” that receiving servers are looking for can be found in your DNS (Domain Name System) records – therefore, you should talk to your IT department about setting up your DNS records before you attempt to send bulk emails. We recommend senders look at getting their DNS set up correctly, as it will reduce the number of bounces.

As receiving email servers are becoming smarter, new levels of DNS record-based authentication are being implemented. A year or two ago, hardly anybody had heard of SPF (Sender Policy Framework), DKIM (Domain Key Identified Mail) or DMARC (Domain-based Message Authentication, Reporting and Conformance), but now they are pretty much essential to know about and apply. These acronyms describe three different types of DNS records or DNS record-based email checks which will affect the deliverability of your email marketing campaigns. The technicalities are explained below.

1. SPF
In an SPF check, the receiving server looks at both the IP address of the mail server the incoming mail is from and the email address that it says the email is from. It will then go and check the DNS records to see if the domain for the email address of the sender and the IP address are listed there in an SPF record. If there is no match, the email will be rejected.

An SPF record may contain many IP addresses which allows for the domain owner to list their IP address and those of a third party.

Example: domain DNS SPF record has “v=spf1 ip4: ip4: -all”
This says that it is ok to accept emails from, which is the office mail server, as well as, which is the IP range that covers the PRODOCOM email delivery system.

So, any email server that receives an email from a email address will check the DNS records, and see that it should only accept emails from the listed IP addresses.

When a sending server employs DKIM it will sign all relevant emails with a “key”. The recipient’s server will see that there is a DKIM-signature in the email header and will then go and check the sender’s DNS record. If the key in the email matches the DKIM record in the DNS, the email is authenticated. If not, the email is rejected.

In order to pass a DMARC check, you have to have first passed either an SPF or DKIM check – so don’t be surprised if there a high number of failures to a particular group (such as public schools in a particular state) who are doing both SPF and DMARC lookups.

DMARC looks deeper into the email received and looks at who the email is from as the user sees it, rather than who the email is from as the mail server sees it. DMARC then provides a set of rules to apply based on the SPF and DKIM results, along with where to report any misalignments.

When you set up your DMARC record, you are providing instructions on what to do and where to send reports. An example DMARC record looks like:

“v=DMARC1; p=reject; adkim=r: aspf=s; rua=; ruf=; pct=100”

The above DMARC record advises servers that recognise DMARC, to

p=reject Reject any email that does not comply.
adkim=r Apply a DKIM match in relaxed mode.
aspf=s Apply strictly to an SPF match.
rua=mailto: Send aggregate reports of mismatches to this email.
ruf=mailto: Send forensic reports of mismatches to this email.
pct=100 Apply these rules to 100% of all emails.

In short, you can see how this DNS record system can have a big impact on your emails. You put SPF, DKIM and DMARC together, and you can make a big difference in both preventing fraudulent emails and ensuring your real emails get through.

4. Spoofing
Spoofing is a term used where an email seems to come from someone but when you look a little closer it actually comes from someone else. If you look closely at the from name and email address for an email you may see something like this;

Paul Edwards < >

There are 2 email fields in play here. The first part is the from name. This is the part that “Spoofers” want you to read. If you only read that bit you would assume that the email came directly from me. However if you then look at what is between the < and > symbols, you will see the real senders email address, which clearly isn’t me.

Why do people use Spoofing? Spoofing is used so that all the other authentication checks are done on the “Spoof” address domain, which in the above case is azxse. So as long as the DNS for is set up ok, the email will pass all the security checks, leaving just the content checking as the last line of defence.

Mail server administrators and security experts are aware of this and are now detecting Spoofing. They will look to see if the “From Name” field has an email address in it and, if it does, if it differs from the “From Email Address”. If the domain differs, which in the above example it does, it will be classified as spam and more often than not, will not be delivered to the intended recipient. Consequently it is now more important than ever to ensure that any third party you use to deliver emails on your behalf do not use the Spoofing technique.

5. Mail Server Email Address
When 2 mail servers initiate a connection, the sending server will provide a “Mail Server Email Address” that the recipient mail server will use to return reports if required. This is completely independent to the email address of the sender of the email. One of the checks that is increasingly becoming part of the DMARC checks is to check that the domain for the “Mail Server Email Address” gets through SPF checks and is the same domain as the “from Email Address” of the sender of the email. Again, if there is a mismatch, the email will most likely get rejected. This is another feature that you need to make sure that any third party email provider has covered.

6. Sender’s Reputation
More and more mail server administrators are signing up to “Sender’s Reputation” services and “Blacklist “ services. In short if your domain is in any way associated with repeated attempts to send to bad email addresses or found to be failing authentication checks, you may end up with a bad sender’s reputation, or on blacklists. This will adversely affect your ability to send emails to anyone that also employs sender’s reputation and blacklists.

Paul Edwards has been in the field of communications since the 1980’s. As founder and CEO of PRODOCOM for the last 21 years, Paul has been at the forefront of communications technologies, leading not only the business, but also the technology teams at PRODOCOM.

Leave a Reply

Your email address will not be published. Required fields are marked *