Back to main menu

Deliverability

Misfit email series: My email isn’t authentic enough

Is there such a thing as following too little or too many email authentication protocols? Read more -

PUBLISHED ON

PUBLISHED ON

In my last article, I touched on the basics and background behind the various authentication protocols available for senders to utilize in order to show recipients their mail is authentic to their brands.  Recently, I was asked a question; “What if my mail isn’t authentic enough?” Today, I’ll walk through potential problems and solutions of improper email authentication, so pull up a chair and get comfy.

Email authentication protocols are technical things.  As with all technical things, if they aren’t implemented properly there can and will be consequences.  Some will be a minor inconvenience, others can be quite catastrophic. In this blog, I’d like to highlight some of the more prominent cases where our customers don’t quite get their email authentication right and what to do about them.

Problem – Multiple SPF DNS Records

Since Mailgun can often act as a secondary source of outbound mail for a domain, we see customers struggle to properly implement the SPF records for all of their sending platforms.  One common issue we see is where a customer will add a secondary TXT record for their Mailgun SPF, while their primary SPF remains untouched. An example will help illustrate things and I’ll use our favorite fake domain, meowgun.com, from here on out.  We’ll reference:

dig txt meowgun.com

; <<>> DiG 9.10.6 <<>> txt meowgun.com

;; ANSWER SECTION:

meowgun.com.   869    IN TXT    "v=spf1 include:mailgun.org ~all"

meowgun.com.   869    IN TXT    “v=spf1 ipv4:127.0.0.1 ~all

Here we see both SPF records being returned. The problem this presents to recipient servers is that depending on which record comes back first, the recipient could enforce either the IPv4 record or the include:mailgun.org record. If you don’t feel like trying your luck, there is a better way.

Solution

The solution here is quite simple: combine the records into one neat SPF TXT entry that uses proper syntax. SPF syntax is pretty flexible in allowing quite a lot of mail sources into a small TXT record – provided you’ve done your homework.  Here is how we would recommend integrating the records in the above scenario:

“v=spf1 ipv4:127.0.0.1 include:mailgun.org ~all”

Now we have one tidy SPF record that covers all our mail sources.

Sign Up

It's easy to get started. And it's free.

See what you can accomplish with the world’s best email delivery platform.

Problem – Too Many SPF lookups

SPF specifications cap the amount of DNS lookups that can be done on behalf of an SPF record at 10.  Here are all of the SPF mechanisms that will trigger a DNS lookup:

  • Badge Check

    A

  • Badge Check

    Exists

  • Badge Check

    Include

  • Badge Check

    MX

  • Badge Check

    PTR

For some senders with an abundant source of mail streams for their domain, it doesn’t take very long for their SPF records to get unwieldy and end up implementing a record over the allowed limit.

Solution

In regards to this issue, there’s not a one size fits all solution and it will really depend on the sources of mail for a sender.  That being said, there are some general recommendations we can pass along to help guide you:

  • Badge Check

    Know how many lookups are used in your include mechanism. Includes can be nested and result in more than 1 lookup.  Mailgun’s SPF record falls under this category and requires 3 lookups in total due to the nested includes.

  • Badge Check

    Don’t use PTR mechanisms.  

  • Badge Check

    Since IPv4 and IPv6 mechanisms reference IPs directly, they require no DNS lookup and you can use them to your heart's content.

  • Badge Check

    Most web servers and few inbound MX servers are setup properly to send mail, so be careful about using the A or MX mechanisms if they are not absolutely necessary.

  • Badge Check

    For some companies, sources of email change regularly so be sure to review the full SPF record occasionally and remove any unnecessary entries.  The global DNS system thanks you.

  • Badge Check

    NO. PTR. MECHANISMS.

To be serious for a moment, the PTR mechanism can get out of hand rather quickly due to the implementation and you won’t find many reputable vendors who recommend it.

Problem - Some of my Mailgun messages have multiple DKIM signatures

Sometimes when testing or getting feedback from an email recipient, our customers will notice that some messages sent by the Mailgun platform have more than the DKIM signature in the headers of the message.  They’ll often reach out to our support team and inquire as to why that happens, and if their messages are misconfigured in any way.

Solution

No need to worry, your messages are not misconfigured and there is nothing nefarious going on with messages that have multiple DKIM signatures. Mailgun will dual DKIM sign messages when they are sent to providers which require an ESP DKIM signature as part of their feedback loop systems.

Gmail and Verizon Media Group (Yahoo/AOL/Verizon) are the biggest names that have this style of feedback loop in place. As such, our reputation and engineering teams decided we’ll dual DKIM sign messages to those systems to ensure that we are able to get their feedback for our customers. Double authenticated messages and feedback from ESPs is a win/win.

Problem - Should I inherit my root domain DKIM authority to a subdomain?

As the theoretical admins for Meowgun.com, a well established brand of the finest cat memes on the internet with the goal of global meme domination, we want to expand our sending domains to cover some new areas: transactional sends and marketing campaigns. Therefore, transgressions.meowgun.com and meowketing.meowgun.com are chosen to handle those two new mail streams.  These domains will join meowgun.com on our Mailgun account, and by default, they will automatically inherit the DKIM authority of meowgun.com. 

 But should they?

Solution

Once again, there’s no one size fits all answer here, but the key considerations are the comfort level of domain reputation overlap, the comfort level with a domain warm-up procedure, and the lifespan of the mail stream.

Separate

  • Badge Check

    If you don’t want any reputation overlap between mail streams, separate is your answer.  Each version of the domain will have little to no reputation bearing on the others.

  • Badge Check

    Separate will mean the new domains will have no reputation among providers, so consider an appropriate warm-up strategy

  • Badge Check

    Mail streams that will have a considerable lifespan are best kept separate.

Inherit the root

  • Badge Check

    If reputation overlap isn’t a big deal, inherit away.  Be careful with marketing streams here because marketing engagement is generally lower than transactional or person to person message engagement and could have a negative effect on domain reputation for the primary domain.

  • Badge Check

    Need to bypass a new domain warm-up, consider inheriting. Reputation degradation as mentioned above applies here too.

  • Badge Check

    Need a short term mail stream (few weeks to a month) on a smaller volume scale with a high engagement audience, consider inheriting.

The last thing to keep in mind about the DKIM authority is that you are not locked into your choice once made. The setting can always be changed by calling our Domains API or by reaching out to our support team, but reputation considerations will still apply when changed.

Problem - I implemented a DMARC rejection policy and valid mail got blocked!

As DMARC implementations by recipient systems continue to gain traction in the industry and adoption rates climb, implementing a smart DMARC policy can bring real dividends to a sender’s reputation. We have plenty of security conscious customers who want to apply the strictest p=reject policy right away.  It always seems like a good idea until they get reports about valid mail being blocked due to the policy and upset customers wondering where their mail went.

Solution

Patience pays off here. Countless customer interactions have told us it is better to implement a p=none policy for an extended period of time before attempting a stricter policy. This allows time for the policy admins to receive reports on all mail failing policy and adjust the DMARC record or the mail stream appropriately. Consider a few weeks to a month for the time period to try and account for all mail streams and their respective cadences. Once all valid streams are passing policy, then start opting for a stricter p=quarantine or p=reject policy to being reaping the domain reputation rewards.

This is only the beginning

Hopefully some of these scenarios will be helpful to our customers with their implementations of the various email authentication protocols. However, there’s a lot more to explore with each authentication protocol, but don’t panic. If you still have questions or concerns about your email authentication protocols, don’t hesitate to reach out to our support folks who are more than happy to help enlighten you on your email sending journey.

Sign Up

It's easy to get started. And it's free.

See what you can accomplish with the world’s best email delivery platform.

Related readings

Gmail expands BIMI support: What it means for email senders

Email authentication and brand protection are key ingredients for a successful email program. Google's latest updates to its BIMI support for Gmail ...

Read More

What is SMTP and how does it work?

SMTP, though a pillar of email delivery, often gets lost in the jumble of tech terms and acronyms. But if you're ready to send impactful emails, this is one of those acronyms that...

Read More

Key rotation best practices: Keeping your email program secure

Many of us have been managing passwords for decades. Maybe it started with your Neopets account, but somewhere in the early 90s, password protection joined the conversation and never left.  

Read More

Popular posts

Email inbox.

Email

5 min

Build Laravel 11 email authentication with Mailgun and Digital Ocean

Read More

Mailgun statistics.

Product

4 min

Sending email using the Mailgun PHP API

Read More

Statistics on deliverability.

Deliverability

5 min

Here’s everything you need to know about DNS blocklists

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