Email authentication: Your ID card for sending

Email authentication lets a receiving mailbox provider know that you are a trusted sender. It’s the email version of a driver’s license and you can’t cruise the highways of email without it. But what does email authentication entail? And how does it secure your identity?



Think about it this way: Email authentication lets mailbox providers know that you are who you say you are, and your emails are coming from you and not a spammer. It’s kind of like a driver’s license or an ID card – legit ones, that is.

Email authentication is comprised of various methods for taking ownership and accountability of your email and server. Plus, it makes it a little harder for spammers to disguise themselves as you – a real ID will get you past the bouncer at a club, but so can a good fake. Authentication forces inbox providers to verify your ID is real.

What is email authentication?

Email authentication verifies sender identity using multiple methods to separate messages sent by real senders from forged ones. As a Technical Account Manager at Mailgun, I’m constantly talking to my customers about how to protect against fraud, spoofing, phishing scams, and how to stay out of the spam folder. One of best practices is securing with email authentication.

Different providers may require different authentication setups. Required details like which authentication protocols you need and what conditions you need to configure can vary but going without authentications can get you marked as a fake sender even if you’re not.

Establishing brand legitimacy

Email authentication isn’t the most glamorous part of sending email. It’s not as fancy as building templates or copywriting the overall email message, but without it, your emails are more likely to land in the spam folder. Better email deliverability starts all the way at the beginning with initial setup and authentication.

Plus, having the right email authentication in place lets mailbox providers like Gmail catch phishers and fake emails faster – something we can all get behind.

How email authentication works

Email authentication works by using DNS records to verify different aspects of your sender identity. Some records let the receiving server validate the hosts that are allowed to send messages from a specific domain, and others verify sender identity with public-keys and electronic signatures. The policy you set is up to you and the record types you choose.

The authentication process works like this:

  1. A business develops a policy to manage how email sent from its domain name is authenticated.

  2. The email sender configures its mail servers to implement and enforce the policy.

  3. The recipient’s server authenticates the message it receives against the business's authentication policy.

  4. If authenticated, the recipient’s server accepts the message. If it fails authentication the message is managed based on the policy in place:

  • Deliver it to the inbox anyway

  • Allow the message through but send it to the spam folder

  • Reject the message (blocking it from deliver)

Email authentication methods

An email authentication method is any technical standard that makes domain-based email authentication possible. The elements that are being verified can vary from method to method, but they were all designed as standards to support Simple Mail Transfer Protocol (SMTP) – the main protocol (other than API) used to send email. SMTP works well, but it doesn’t have built-in security which is why authentication methods exist.

The most common email authentication protocols are SPF and DKIM, and others like DMARC and BIMI are starting to become more widely used.

Sender Policy Framework (SPF)

Sender Policy Framework (SPF) was the first real attempt at an email authentication protocol, devised in the early 2000, SPF utilizes a Domain Name System (DNS) TXT record to specify which email sources are valid email senders for the given domain and what to do with the messages that don’t originate from those sources. It acts as a digital bouncer; if you aren’t cool enough to be on the list, you’re likely to get kicked to the curb (or land in the spam folder).

Image shows the SPF authentication flow from the sender, to the inbound mail server and DNS, to the authentication policy.

An SPF record consists of a collection of mechanisms and qualifiers. The mechanisms are methods for identifying email servers while the qualifiers tell us what to do with those mechanisms. Sounds simple, right? SPF records are necessary but that’s not to say they don’t have some limitations. Here are some:

  • Only one valid SPF record is allowed per domain. Multiple records can confuse recipient systems.

  • SPF implementation MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check. (This does take into account INCLUDE and REDIRECT mechanisms.)

  • We recommend using ~all as the final entry in the record, but we certainly accept -all as well.

  • We do support SPF recording chaining for whitelisting. See this blog for details.

SPF records consist of a collection of mechanisms and qualifiers that tell mailbox providers who should be sending mail on behalf of a domain.

While SPF works great in most situations, there are some circumstances where it doesn’t quite hold up, like with forwarded messages. Forwarded messages will have the same original sending domain, but it will likely be sent by a server that isn’t specified in the sending domain’s SPF record. The likely outcome is messages being tagged as spam unintentionally or the messages being dropped altogether.

The biggest problem with SPF authentication is that bad actors can exploit it with a fake domain in the Return Path address and forging the From address to make the email look legitimate. That means SPF not the most effective way to stop brand spoofing.

With such a glaring issue within the framework, it wasn’t long before email authentication was looked at from a different angle.

Domain Keys Identified Mail (DKIM)

DKIM authentication is a technique allowing recipients to validate certain digital aspects of the email by matching a public key with a private key to verify the message was authorized by the owner of the domain it was sent from. Once signed cryptographically, the receiving mail server validates the public key against the private key.

In the signature, you can specify specific message header fields and components that you would like to sign against. However, the “From” field is the one message aspect that must be included in the signature.

In plain English, a DKIM record allows a sender to say, “I’ve signed parts of this message digitally and using my public key, you can validate that what I’ve sent you hasn’t been modified in any way, and you can rest assured it was sent from my domain.” A bit of a mouthful, but you get the picture.

Longer DKIM keys equal more protection from spammers. Our current default key size is 1024 bits, but we have recently updated our system to be able to generate and utilize 2048 bit keys. 2048 bit keys offer stronger encryption but will generate a larger TXT record as a result, so you may need to consult with your DNS service provider about formatting.

Image shows DKIM authentication flow an email with DKIM signature (private key), to the receiving mail server and DNS server, to the authentication policy (public key) to authentication.

DKIM is an excellent resource for ESPs to track a domain’s reputation because signing messages via DKIM is considered authoritative. As an ESP we take care of a lot of the DKIM heavy lifting on your behalf; however, there are some customization options.

At Mailgun, our standard recommendation is to have your sending domain be a subdomain off your main root domain. As such, our customers have the option of setting the DKIM authority to either be that subdomain or the root with the caveat that both domains are setup within your Mailgun account.

Let’s say your main root domain name is (because cats indeed rule), but you’ve set your Mailgun sending domain name as By default, our system will want to set the DKIM authority for both domains to, but by using our API, you can overrule that and have have its own value instead. This value can be changed at any time but be aware that it can have ramifications for your domain reputation.

Make sure you’re properly warming your domain and IPs before sending to help improve deliverability and reputation.

Domain Message Authentication Reporting and Conformance (DMARC)

There wasn’t anything to tie SPF and DKIM together until DMARC entered the picture.

Domain-based Message Authentication Reporting and Conformance (DMARC) gives domain owners better control over SPF and DKIM and makes these policies easier to handle.

DMARC records:

  • Signal whether SPF and/or DKIM authentication is in place for the domain.

  • Suggest how to handle messages that fail to align with those protocols.

  • Direct how to give feedback to the sender.

A DMARC policy is principally concerned with the alignment of the “From:” field with the authentication mechanisms listed in the SPF or DKIM policy for the domain. In other words, DMARC helps ensure recipients know exactly what to do with a message that fails either SPF or DKIM, while also letting the recipient notify the sender via the reporting function as to how the message performed.

Image shows how a DMARC policy works from an email with SPF/DKIM through the mailbox provider, to verifying DMARC implementation, passing DMARC authentication, and applying the DMARC policy to deliver to sender.


Our best words of wisdom regarding DMARC implementation is to start with a p=none policy. A none policy will ensure that messages are scanned according to your DMARC policy alignment specifications, but no action is taken on them. In other words, the none policy tells your recipient’s email provider not to take action against your message if DMARC fails.

There are two other DMARC policy types:

  • The p=quarantine policy separates suspicious emails by placing them somewhere like a spam folder, instead of the inbox.

  • The p=reject policy tells the provider to block any email that fails DMARC. With the reject policy, a message failing DMARC will never see the inside of the inbox.

The value in using the none policy is that reports will still be generated for those domains. You can use reports to verify the SPF and DKIM alignment policies. Once you confirm DMARC is working as it should, you must update the policy and instruct receiving mail servers to either quarantine or reject failures moving forward. This is critical, because a relaxed p=none policy does nothing to make your authentication stronger or make the inbox a safer place for subscribers.

Reverse DNS/Pointer (PTR) Records

Setting up your reverse DNS/PTR records is step one when implementing DMARC. Reverse DNS works by resolving a domain’s DNS (name) to an IP address, rather than resolving an IP address to a domain name. The last point of authentication comes at the server end of things with Reverse DNS or Pointer (PTR) records.

All mail servers will have a sending IP address that is used to talk to other servers, but we also recommend that a human-friendly name is attached to that IP address. Reverse DNS records and PTR records make it easy to identify the server when looking at mail logs and email headers, so you don’t have to memorize IP addresses.

At Mailgun, all of our shared and dedicated IP space comes with a preconfigured PTR record. So, no matter your account or IP type, you are covered by default.

For accounts with dedicated IPs we offer assistance setting up a custom PTR record with your sending domain. This allows for a final layer of authentication at the IP level.


There are two types of DMARC reports that recipients can send to DMARC-authenticated domain owners, aggregate reports and forensic reports.

Aggregate reports will usually be sent daily by recipient servers and collect various statistics for a sending domain. A typical aggregate report will be in XML format and include details on the sending IP, SPF/DKIM alignment passes or failures, and the header FROM domain, along with counts of each message.

Forensic reports, on the other hand, will show real-time DMARC message alignment failures, including a redacted copy of the original message which triggered the failure. Domain owners should utilize these ‘failure reports’ to understand their failures (message failures, not personal/professional) and address any issues uncovered.

Implementing DKIM and DMARC is more important now than ever. As of Q1 2024, both Gmail and Yahoo will be activating some hefty updates regarding the responsibilities of senders. Proving authentications is a mandatory part of the update for both of these mailbox providers, but that’s not all. Learn everything you need to know in our Gmail and Yahoo mailbox updates post.

Brand Indicators for Message Identification (BIMI)

BIMI allows you to include a branded sender image using your brand’s logo along with your message. Not only does BIMI provide brand recognition at a glance, but it’s a DNS TXT record that provides additional authentication.

Mobile devices with and without inbox logos

Think of BIMI as the icing on the cake. After you’ve jumped through the hoops and configured all your authentication standards, you become eligible for a BIMI record but there is a caveat. For BIMI to work, your DMARC policy must be set to either quarantine or reject.

We still recommend starting with p=none when you implement DMARC – this is a great way to test DMARC configurations and reporting, but it shouldn’t be your ongoing standard as it doesn’t protect against phishing or spoofing. BIMI requires p=quarantine or p=reject as part of a larger movement to enforce stricter DMARC policies.

Email authentication: The last defense

Email authentication encompasses deliverability, reputation, and security. Email authentication isn’t just about securing your identity, it’s a deciding factor in message filtering. At the end of your email’s journey when the ISPs are deciding whether to let your message into the inbox, authentication gets you past the spam filters.

So, there’s really only one question: Is your identity junk? Or is it worth authenticating.

There’s a lot more to implementing and understanding email authentication protocols, and security goes far beyond authentication. Curious about other ways to secure your email program? We are too. So curious, in fact, that we gathered our most dedicated security and deliverability email geeks to put together a comprehensive guide. Check it out for everything you need to know about email security and compliance.

Learn about email security and compliance

Email security and compliance

Email security isn't easy. But you need to protect your business, brand, employees, and subscribers. Find out about the benefits of continually improving email security and compliance from our industry experts, and learn to tell if your technology partners have what it takes to do the same.

Related readings

What is Authenticated Received Chain and why should you care?

Authentication has been a top-of-mind topic in the email world for some time, but it feels like the buzz has grown after the announcements made by Google and Yahoo in October...

Read more

Understanding the Gmail and Yahoo sender requirements: Takeaways from our fireside chat with Gmail and Yahoo

The inbox requirements for bulk senders announced by Google and Yahoo in October 2023 have shot through the community like panic up a spine. As with any big announcement it...

Read more

Gmail and Yahoo’s 2024 inbox protections and what they mean for your email program

As senders, we should be the first to care about sending valuable, relevant emails to our contacts. Ultimately, email’s efficiency as a communications channel depends on our...

Read more

Popular posts

Two men talking about email authentication

Build Laravel 10 email authentication with Mailgun and Digital Ocean

When it was first released, Laravel version 5.7 added a new capability to verify user’s emails. If you’ve ever run php artisan make:auth within a Laravel app you’ll know the...

Read more

Gods with gears in city street

Sending email using the Mailgun PHP API

It’s been a while since the Mailgun PHP SDK came around, and we’ve seen lots of changes: new functionalities, new integrations built on top, new API endpoints…yet the core of PHP...

Read more

God with mask on chair

Here’s everything you need to know about DNS blocklists

The word “blocklist” can almost seem like something out of a movie – a little dramatic, silly, and a little unreal. Unfortunately, in the real world, blocklists are definitely something you...

Read more

See what you can accomplish with the world's best email delivery platform. It's easy to get started.Let's get sending
CTA icon