Misfit email series: My email isn’t authentic enough

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.

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:

• A

• Exists

• Include

• MX

• 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:

• 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.

• Don’t use PTR mechanisms.  

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

• 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.

• 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.

• 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

• 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.

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

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

Inherit the root

• 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.

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

• 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.