On this page
  1. Does Mailgun mail pass DMARC?
  2. The DNS records Mailgun shows
  3. US and EU region values
  4. SPF: include:mailgun.org
  5. DKIM: a TXT key or Automatic Sender Security
  6. Subdomain or root domain?
  7. The DMARC record to publish
  8. Check your domain
  9. Sources

Publish a DMARC record as a TXT record at _dmarc.example.com, starting with v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com, which you can build in the DMARC generator; RFC 9989 (opens in a new tab) places the record for example.com at that name. Mailgun mail can pass it. Mailgun's DMARC article (opens in a new tab) lists three conditions: the DKIM record for your Mailgun sending domain is published and verified by Mailgun, the From address uses that sending domain or its root domain, and a DMARC record exists.

Does Mailgun mail pass DMARC?

It does when the domains line up. RFC 9989 (opens in a new tab) checks the Author Domain, which RFC 9989 section 3.2.2 (opens in a new tab) defines as the domain in the From header, against the authenticated domains. Relaxed alignment accepts the same organizational domain, strict alignment needs an identical name, and the domain owner picks the mode in the DMARC record. For DKIM, the authenticated domain is the signing domain of a signature that validates. For SPF, DMARC uses only the MAIL FROM domain that SPF validated. DMARC needs SPF or DKIM to pass, in alignment.

Mailgun's DMARC article (opens in a new tab) turns that into the checklist above. The From domain must match the Mailgun domain you authenticate and send through: if you send through marketing.example.com, the From address uses marketing.example.com or example.com.

The From domain is your choice. In Mailgun's sending FAQ (opens in a new tab), the sender must always be one of your Mailgun domains, while the From domain need not match it; Mailgun recommends the same domain in both for deliverability.

Mailgun warns about strict SPF alignment. Its example: with a strict policy, a mail-from of mg.example.com and a From of example.com fail, and with a relaxed policy they pass. So if you authenticate and send with a subdomain but use the root domain in the From address, aspf=s breaks SPF alignment; Mailgun's advice is relaxed, which is the default when the tag is absent. That alone does not fail DMARC: RFC 9989 counts a message as a DMARC pass if any DKIM-authenticated domain aligns, and DKIM alignment is also relaxed unless the record sets adkim=s (RFC 9989 section 4.7 (opens in a new tab) makes r the default). DMARC fails only when neither SPF nor DKIM aligns. If a header still shows a failure, DMARC fail walks through reading it. To confirm, Mailgun's article suggests reading the headers of received messages to see whether SPF, DKIM and DMARC verified.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

The DNS records Mailgun shows

In Mailgun's Domain Verification Setup Guide (opens in a new tab), you open Sending, then Domains, click Add New Domain, and the next screen asks you to add the DNS records. The guide recommends a subdomain and uses mail.example.com-style hosts in its example. For a sending domain of mg.example.com, the records look like this:

Purpose Type Host Value
SPF TXT mg.example.com v=spf1 include:mailgun.org ~all
DKIM (key in DNS) TXT pic._domainkey.mg.example.com or another assigned selector the public key Mailgun shows
DKIM (Automatic Sender Security) 2 × CNAME pdk1._domainkey.mg.example.com, pdk2._domainkey.mg.example.com the targets Mailgun shows
Receiving 2 × MX mg.example.com mxa.mailgun.org, mxb.mailgun.org, priority 10
Tracking CNAME email.mg.example.com mailgun.org

The SPF value and the MX and tracking targets come from Mailgun's domain verification page (opens in a new tab). The DKIM host name varies: the Domain Verification Setup Guide uses mx._domainkey in its example, and Mailgun's Cloudflare guide (opens in a new tab) shows pic._domainkey, with krs._domainkey, smtp._domainkey and mailo._domainkey as other possibilities. Use only the selector Mailgun assigned to your domain. The two CNAME rows are the Automatic Sender Security (opens in a new tab) option, covered in the DKIM section below.

Which records you need depends on what you use. In Mailgun's DNS FAQ (opens in a new tab), the two TXT records, SPF and DKIM, are all that is required to send, and the CNAME is needed only for tracking clicks, opens and unsubscribes. Mailgun's tracking documentation (opens in a new tab) adds that the CNAME to mailgun.org is what lets Mailgun rewrite links and track opens.

MX is less clear-cut. Mailgun's FAQ (opens in a new tab) recommends MX records for all domains, because ISPs commonly use them as a verification step, and requires them if you want to receive email at the domain you added to Mailgun. The Cloudflare guide calls them technically optional but virtually required for deliverability and for avoiding some bounces, such as those from Sender Address Verification, and the domain verification page lists them as required for Mailgun to receive and route messages for the domain. The exception: the FAQ says that if you send through several servers but do not want to receive email at Mailgun, you simply do not point MX records to it, and the DNS FAQ advises against it when the domain already receives mail elsewhere. In that case Mailgun recommends a subdomain, so you can still receive email at Mailgun on it.

The tracking host name is email in Mailgun's examples. Mailgun's HTTPS tracking article (opens in a new tab) makes it configurable in the Mailgun application, and through the API it is the domain's web prefix (opens in a new tab); either way, the CNAME host name must match. A CNAME on a host name hides any other record there, so pick a name your other DNS records do not use. DNS changes can take 24 to 48 hours to propagate; then open Sending, then Domain settings, then the DNS records tab, and click Check status.

US and EU region values

You choose the region when you add the domain: Mailgun's custom domain steps (opens in a new tab) include Select Domain region. Per Mailgun's region article (opens in a new tab), the region of a domain cannot be changed once it has been created, and the same domain cannot exist in both regions. The regional differences cover SMTP, the API, MX records and click tracking. Mailgun's API overview (opens in a new tab) lists the endpoints:

Service US EU
REST API api.mailgun.net api.eu.mailgun.net
Outgoing SMTP smtp.mailgun.org smtp.eu.mailgun.org
Inbound MX mxa.mailgun.org, mxb.mailgun.org mxa.eu.mailgun.org, mxb.eu.mailgun.org
Open and click tracking mailgun.org eu.mailgun.org

So for an EU domain, the MX records point to the eu hosts and the open and click tracking endpoint is eu.mailgun.org rather than mailgun.org. Message data stays in the region where it is processed, and dedicated IPs are bound to one region. For SPF, checked against live DNS, the mailgun.org SPF record includes both _spf.mailgun.org and _spf.eu.mailgun.org. Copy the exact values from your domain's DNS records page either way.

SPF: include:mailgun.org

Mailgun's DNS FAQ (opens in a new tab) allows only one SPF record per host name. If the sending domain already has one, place include:mailgun.org anywhere after v=spf1 and before ~all instead of adding a second record:

v=spf1 include:_spf.example.com include:mailgun.org ~all

When the sending domain is a subdomain, Mailgun's domain verification guide (opens in a new tab) puts a new TXT record on the subdomain itself, so mg.example.com gets its own SPF record. Using -all instead of ~all makes no difference to verification in Mailgun (Mailgun's Cloudflare guide (opens in a new tab)).

Watch the lookup count. RFC 7208 (opens in a new tab) counts include, a, mx, ptr, exists and redirect as terms that cause DNS queries, limits them to 10 per evaluation, and returns permerror past that. An include is evaluated recursively (RFC 7208 section 5.2 (opens in a new tab)), so the includes inside it count too, as the SPF record generator also notes; it lists Mailgun as include:mailgun.org. Checked against live DNS:

  • mailgun.org publishes v=spf1 include:_spf.mailgun.org include:_spf.eu.mailgun.org -all.
  • _spf.mailgun.org publishes v=spf1 include:_spf1.mailgun.org include:_spf2.mailgun.org ~all.
  • _spf1.mailgun.org, _spf2.mailgun.org and _spf.eu.mailgun.org list ip4 ranges only.

That makes include:mailgun.org cost five of your ten lookups: mailgun.org, _spf.mailgun.org, _spf.eu.mailgun.org, _spf1.mailgun.org and _spf2.mailgun.org. Mailgun's DNS FAQ also warns to keep the record to no more than 10 lookups. If the domain already sends through other services, SPF too many DNS lookups shows how to count and trim.

DKIM: a TXT key or Automatic Sender Security

Mailgun signs with one of two setups, both described on Mailgun's DKIM security page (opens in a new tab).

With a TXT key, the public key sits in your DNS under a selector unique to the sending domain. Most users let Mailgun generate the key, at 1024 or 2048 bits. The 2048-bit record is significantly longer, and some DNS providers require it split into two parts. A domain can hold up to three active DKIM keys, and Mailgun picks one per message, round robin.

With Automatic Sender Security, you add two CNAME records instead, and the keys live on Mailgun's side. The host names look like pdk1._domainkey.mg.example.com and pdk2._domainkey.mg.example.com, pointing to targets such as pdk1._domainkey.9d876.dkim1.mailgun.com; that target is Mailgun's documentation example, and checked against live DNS it does not exist, so copy your own. Because the key is hosted by Mailgun, Mailgun can rotate keys without changes in your DNS: every 120 days by default, with 5 days as the shortest interval. You can turn it on when adding a new domain, or switch an existing TXT-key domain from the DNS records page. Mailgun's DNS FAQ (opens in a new tab) adds that active manual keys are deactivated once the Automatic Sender Security CNAMEs verify.

Either way, the receiver finds the key by selector: RFC 6376 (opens in a new tab) builds the query name from the s= and d= tags of the signature, so s=pdk1 with d=mg.example.com is looked up at pdk1._domainkey.mg.example.com. DKIM selector covers finding the selector in a message header.

Subdomain or root domain?

Mailgun's domain name article (opens in a new tab) recommends mg.example.com or mail.example.com, and the root domain only if you do not already use it for corporate email. Mailgun's DNS FAQ (opens in a new tab) calls a subdomain its standard recommendation.

Mailgun's FAQ (opens in a new tab) explains that only one mail server can receive messages for a domain, while several can send for it. If your domain receives email elsewhere, Mailgun recommends a subdomain for Mailgun, and the DNS FAQ warns against pointing a domain's MX records to Mailgun when incoming mail is set up elsewhere. In Mailgun's Cloudflare guide (opens in a new tab), another provider's MX records alongside Mailgun's result in unpredictable delivery, in short lost emails.

Separate subdomains also separate reputations: the domain name article describes some companies using different subdomains for bulk marketing and for transactional or corporate mail to keep their reputations apart.

The DMARC record to publish

Mailgun can generate one. In Mailgun's DMARC reporting article (opens in a new tab), Mailgun generates the record during domain setup, after you agree to the Red Sift end user license agreement on the DNS page; it shows when you add a new domain or on the DNS page of an existing sending domain. You add it at your DNS provider like the other records.

Mailgun's DMARC article (opens in a new tab) asks for a DMARC record for your sending domains with a policy of at least none. The large mailbox providers set the same floor for bulk senders: Google's sender guidelines (opens in a new tab) require DMARC from senders of more than 5,000 messages a day to Gmail accounts, with a policy that can be none, and Yahoo's sender best practices (opens in a new tab) require bulk senders to publish a valid DMARC policy of at least p=none. If you write the record yourself, the DMARC generator produces the starting point, with rua as the address receivers send daily aggregate reports to:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Publish it at _dmarc.example.com. Mailgun's checklist asks that your Mailgun sending domain has a DMARC record. Under RFC 9989 section 4.10 (opens in a new tab), when mg.example.com has no record of its own, the record of its organizational domain, example.com, applies, and without an sp tag the p policy applies to subdomains (RFC 9989 section 4.7 (opens in a new tab)).

A p=none policy does not change how receivers handle your mail (RFC 9989 section 5.4 (opens in a new tab)); it gets you reports. Read them in the DMARC report analyzer, which shows which sources sent as your domain and whether SPF and DKIM aligned. When your real senders, Mailgun included, pass SPF or DKIM, move to quarantine, then reject, for example v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com. How to set up DMARC covers each step.

Check your domain

The free SPF, DKIM and DMARC check reads the public DNS records of the domain you enter and changes nothing. Run it on example.com and on the Mailgun sending domain. For SPF it flags a missing record, ~all, and a record close to or over the 10-lookup limit; for DMARC it flags a missing record, p=none, no reporting address and subdomains left at none. For DKIM it tries commonly used selectors. If your Mailgun selector is one the check does not try, the result shows not verified: DNS answered, but the key cannot be confirmed from DNS alone. A DNS finding shows how the domain is set up, not where a particular message landed.

Sources

Tools for this

Frequently asked questions

Does Mailgun create a DMARC record for me?

Mailgun generates a DMARC record on the DNS page of your sending domain once you accept the Red Sift licence terms there. You still add that record at your DNS provider yourself.

Do I have to point my MX records to Mailgun?

Not to send: the SPF and DKIM TXT records are all Mailgun requires for sending. Mailgun still recommends MX records for all domains because ISPs commonly check them, and you need them to receive mail through Mailgun. If the domain already receives mail elsewhere, use a subdomain for Mailgun instead of moving its MX records.

Why does SPF alignment fail when I send from my root domain through a Mailgun subdomain?

Check the aspf tag in your DMARC record. With strict SPF alignment (aspf=s), a mail-from of mg.example.com and a From of example.com do not align; with relaxed alignment, the default, they do. DMARC still passes if a DKIM signature aligns, so it fails only when DKIM does not align either.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.