Skip to content
Signet

mailgun.com

Receivers are told to reject mail that fails authentication for this domain.

Enforced

Receivers are told to reject mail that fails authentication for this domain. Keep watching aggregate reports so a new sending service does not silently start failing.

Score held up: DMARC is enforcing at p=reject, so nobody else can send as this domain. That is the hard part, and it is done. What is left below is about your own mail arriving, not about anyone spoofing you -- and some of it may be costing you delivery.

141 DNS queries · 1487 ms

Fix these first
  1. 1
    Report address [email protected] is not authorised to receive your reports
    Ask the owner of dmarc.mailjet.tech to publish a TXT record at 'mailgun.com._report._dmarc.dmarc.mailjet.tech' with the value 'v=DMARC1'.
  2. 2
    Report address [email protected] is not authorised to receive your reports
    Ask the owner of dmarc.mailjet.tech to publish a TXT record at 'mailgun.com._report._dmarc.dmarc.mailjet.tech' with the value 'v=DMARC1'.
  3. 3
    Zendesk can send as your domain but publishes no DKIM key
    Enable DKIM signing in Zendesk and publish the public key it gives you.
  4. 4
    p=reject may be costing you mail from 1 of your own senders
    Best: turn DKIM signing on at Zendesk and publish the key -- that fixes it without weakening anything, and the findings above link each provider's own guide. If it will take weeks and mail is already going missing, moving to p=none while you fix it is not a defeat: an enforcing policy you cannot support is worse than an honest monitoring one. Either way you are guessing until aggregate reports tell you which senders are actually affected and how much mail is involved.

Identity ·Sending services detected

Read from your SPF includes and MX hosts, then checked for a published DKIM key.

MailgunSPF include:_spf.eu.mailgun.org · SPF include:_spf.mailgun.orgkey published · k1, mg
Microsoft 365SPF include:spf.protection.outlook.com · MX mailgun-com.mail.protection.outlook.comkey published · selector1
Salesforce PardotSPF include:aspmx.pardot.comno DKIM key at its selectors
ZendeskSPF include:mail.zendesk.comno DKIM key at its selectors

Identity ·DMARC

v=DMARC1; p=reject; sp=reject; pct=100; fo=1; adkim=r; aspf=r;rua=mailto:[email protected],mailto:[email protected],mailto:[email protected],mailto:[email protected];ruf=mailto:[email protected],mailto:[email protected],mailto:[email protected],mailto:[email protected]
Policy
reject
Coverage
100%
Alignment
dkim=r spf=r

Identity ·DKIM

111 selectors probed

k1Mailchimp / MailgunRSA 1024
mgMailgunRSA 1024
selector1Microsoft 365RSA 2048
googleGoogle WorkspaceRSA 2048
smtpapiSendGridRSA 1024
intercomIntercomRSA 1024
mailjetMailjetRSA 2048

Identity ·SPF

Worst-case evaluation across every include.

v=spf1 include:_spf.mailgun.org include:_spf.eu.mailgun.org include:spf.protection.outlook.com include:aspmx.pardot.com include:mail.zendesk.com ~all
DNS lookup budget8 / 10
  • include:_spf.mailgun.org
  • include:_spf1.mailgun.org
  • include:_spf2.mailgun.org
  • include:_spf.eu.mailgun.org
  • include:spf.protection.outlook.com
  • include:aspmx.pardot.com
  • include:et._spf.pardot.com
  • include:mail.zendesk.com

Findings (16)

HighReport address [email protected] is not authorised to receive your reports›

dmarc.mailjet.tech is outside mailgun.com's organisation, so RFC 7489 requires an authorisation record before receivers will send anything. No authorisation record at mailgun.com._report._dmarc.dmarc.mailjet.tech. Receivers that follow RFC 7489 will not send aggregate reports to this address until that record is published.

What to do

Ask the owner of dmarc.mailjet.tech to publish a TXT record at 'mailgun.com._report._dmarc.dmarc.mailjet.tech' with the value 'v=DMARC1'.

RFC 7489 s7.1

HighReport address [email protected] is not authorised to receive your reports›

dmarc.mailjet.tech is outside mailgun.com's organisation, so RFC 7489 requires an authorisation record before receivers will send anything. No authorisation record at mailgun.com._report._dmarc.dmarc.mailjet.tech. Receivers that follow RFC 7489 will not send aggregate reports to this address until that record is published.

What to do

Ask the owner of dmarc.mailjet.tech to publish a TXT record at 'mailgun.com._report._dmarc.dmarc.mailjet.tech' with the value 'v=DMARC1'.

RFC 7489 s7.1

HighZendesk can send as your domain but publishes no DKIM key›

Zendesk was detected via SPF include:mail.zendesk.com, so it is authorised to send mail as mailgun.com. It always publishes DKIM at fixed selectors (zendesk1, zendesk2), and none of them has a key published. Without one, no DKIM signature it adds for your domain can verify, so its mail has only SPF to align on -- and SPF does not survive forwarding.

What to do

Enable DKIM signing in Zendesk and publish the public key it gives you.

RFC 6376

Highp=reject may be costing you mail from 1 of your own senders›

Being at p=reject is the right place to be, and reaching it is the hard part -- nobody else can send as mailgun.com. The problem is that Zendesk is authorised to send as this domain and publishes no DKIM key, so that mail has only SPF behind it. SPF does not survive forwarding, and a receiver honouring your policy will have it rejected. Nothing here lets anyone else in; it is your own mail at risk.

What to do

Best: turn DKIM signing on at Zendesk and publish the key -- that fixes it without weakening anything, and the findings above link each provider's own guide. If it will take weeks and mail is already going missing, moving to p=none while you fix it is not a defeat: an enforcing policy you cannot support is worse than an honest monitoring one. Either way you are guessing until aggregate reports tell you which senders are actually affected and how much mail is involved.

MediumSPF is close to the lookup limit (8/10)›

You have little headroom. Providers change their own include trees without notice, so a record at 8 or 9 lookups can break without you touching it.

What to do

Trim unused senders now, before a provider's change pushes you over.

RFC 7208 s4.6.4

MediumCould not verify DKIM signing for Salesforce Pardot›

Salesforce Pardot was detected via SPF include:aspmx.pardot.com, so it is authorised to send mail as mailgun.com. We checked the selectors it uses by default (pardot) and found no key. Salesforce Pardot lets you choose your own selector name, so this may simply mean yours is custom. If signing genuinely is not enabled, mail through this service will fail DMARC once forwarded.

What to do

Confirm DKIM is switched on in Salesforce Pardot, then add your selector here so every future scan can verify it directly.

RFC 6376

MediumSelector 'k1' uses a 1024-bit RSA key›

1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

MediumSelector 'mg' uses a 1024-bit RSA key›

1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

MediumSelector 'smtpapi' uses a 1024-bit RSA key›

1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

MediumSelector 'intercom' uses a 1024-bit RSA key›

1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

LowSPF ends in '~all' (softfail)›

Softfail is the correct setting while you are still discovering senders, but it asks receivers to accept unauthorised mail and merely note it.

What to do

Once your aggregate reports show no unexplained legitimate sources, tighten to '-all'.

LowNo MTA-STS policy›

Without MTA-STS, mail to your domain can be downgraded to plaintext by an active network attacker, because SMTP's STARTTLS is opportunistic by default.

What to do

Publish a TXT record at _mta-sts.mailgun.com and a policy file at https://mta-sts.mailgun.com/.well-known/mta-sts.txt.

RFC 8461

LowNo TLS-RPT record›

Sending servers have no address to report TLS failures on mail to your domain, so transport problems stay invisible to you until someone complains.

What to do

Publish 'v=TLSRPTv1; rua=mailto:<address>' at _smtp._tls.mailgun.com.

RFC 8460

LowNo CAA record›

Any certificate authority in the world may issue a certificate for this domain. A mis-issued certificate can be used to intercept mail on the wire and to impersonate your domain over HTTPS.

What to do

Publish a CAA record naming your certificate authority, for example: 0 issue "letsencrypt.org"

RFC 8659

InfoEligible for BIMI›

Your DMARC policy is already enforcing, which is the hard prerequisite for BIMI. Publishing a logo is now largely a branding exercise.

What to do

Publish an SVG Tiny PS logo plus a VMC, then add a default._bimi record.

InfoZone is not signed with DNSSEC›

This is the common case and not a misconfiguration -- most working mail domains are unsigned. It is worth knowing because your authentication records are only as trustworthy as the DNS answers carrying them, and because DNSSEC is the prerequisite for DANE.

What to do

If your DNS provider supports one-click DNSSEC, enabling it is low risk. If it does not, this is not worth changing providers over.

RFC 4033

Show 14 passing checks
PassAggregate reporting is configured›
PassExternal report destination inbox.ondmarc.com is correctly authorised›

Authorised by mailgun.com._report._dmarc.inbox.ondmarc.com

PassExternal report destination mailgun.net is correctly authorised›

Authorised by mailgun.com._report._dmarc.mailgun.net

PassExternal report destination ag.us.dmarcian.com is correctly authorised›

Authorised by mailgun.com._report._dmarc.ag.us.dmarcian.com

PassExternal report destination inbox.ondmarc.com is correctly authorised›

Authorised by mailgun.com._report._dmarc.inbox.ondmarc.com

PassExternal report destination mailgun.net is correctly authorised›

Authorised by mailgun.com._report._dmarc.mailgun.net

PassExternal report destination fr.us.dmarcian.com is correctly authorised›

Authorised by mailgun.com._report._dmarc.fr.us.dmarcian.com

PassDMARC policy is p=reject›

Mail failing authentication is rejected outright. This is the correct end state.

PassMailgun's DKIM keys are published at k1._domainkey, mg._domainkey›

Detected via SPF include:_spf.eu.mailgun.org, SPF include:_spf.mailgun.org. A valid public key for this service is published at k1._domainkey.mailgun.com, mg._domainkey.mailgun.com.

PassMicrosoft 365's DKIM key is published at selector1._domainkey›

Detected via SPF include:spf.protection.outlook.com, MX mailgun-com.mail.protection.outlook.com. A valid public key for this service is published at selector1._domainkey.mailgun.com.

Pass7 DKIM key(s) published›

Found at: google, intercom, k1, mailjet, mg, selector1, smtpapi.

PassSelector 'selector1' uses a 2048-bit RSA key›

Key length meets current guidance.

PassSelector 'google' uses a 2048-bit RSA key›

Key length meets current guidance.

PassSelector 'mailjet' uses a 2048-bit RSA key›

Key length meets current guidance.

Transport and zone

Where your mail lands, and whether the DNS carrying your records can be trusted.

MXmailgun-com.mail.protection.outlook.com
Reverse DNSforward-confirmed on every host
MTA-STSnot published
TLS-RPTnot published
BIMInot published
DNSSECzone not signedCommon and not a misconfiguration.
CAAno record · any CA may issue
DANEno TLSA records

This is the configuration. It is not the whole picture.

A DNS scan cannot tell you whether mailgun.com’s mail actually aligns, because alignment is decided per message at the receiver. Collect DMARC aggregate reports to see every source sending as this domain.

mailgun.com scores B for SPF, DKIM and DMARC · Signet