How to Monitor MX, SPF, DKIM, and DMARC Records

Email delivery is almost entirely driven by DNS records. Get them right and email flows without issue. Get them wrong — or let them change unexpectedly — and emails bounce, go to spam, or stop sending entirely.

The problem is that DNS records can change without warning: a misconfigured deployment, an accidental edit in a DNS dashboard, a nameserver migration that missed copying a record, or in worse cases, a DNS hijacking attack. Monitoring catches these changes before they silently destroy your email deliverability.

The Four Records That Matter for Email

MX Records — Mail Routing

MX (Mail Exchange) records tell the internet where to deliver inbound email for your domain. Without correct MX records, nobody can send you email.

yourdomain.com    MX    10    aspmx.l.google.com     (Google Workspace)
yourdomain.com    MX    20    alt1.aspmx.l.google.com

What breaks when MX records are wrong:

• Inbound email bounces immediately with an SMTP error
• Senders receive "Recipient address rejected" or "No MX record found" errors
• You receive no error yourself — you just stop getting email

MX record failures are silent on the receiving end. You won't know inbound email is failing unless you're monitoring the records or someone contacts you through another channel to say their emails are bouncing.

SPF Records — Sender Authentication

SPF (Sender Policy Framework) is a TXT record that lists which mail servers are authorised to send email on behalf of your domain:

yourdomain.com    TXT    "v=spf1 include:_spf.google.com include:mailgun.org ~all"

The ~all suffix means "soft fail" — emails from unlisted servers are marked as suspicious but not rejected. -all (hard fail) rejects them outright.

What breaks when SPF is wrong:

• Emails you send go to recipients' spam folders
• Recipients' mail servers may reject your email entirely
• Outbound email deliverability degrades, often gradually and invisibly

SPF failures typically don't generate bounce notifications — emails just go to spam, and you find out when someone tells you, or when you check email analytics.

DKIM Records — Email Signing

DKIM (DomainKeys Identified Mail) uses a public/private key pair to cryptographically sign outbound emails. The private key is held by your mail provider; the public key is published in a DNS TXT record:

google._domainkey.yourdomain.com    TXT    "v=DKIM1; k=rsa; p=MIGfMA0G..."

Recipient mail servers verify the signature against the public key in DNS. If the signature is valid, the email passes DKIM.

What breaks when DKIM is wrong:

• DKIM failures lower email reputation and increase spam likelihood
• Some strict DMARC policies will reject emails that fail DKIM
• Deliverability degrades, often without obvious error messages

DKIM records have a long, complex value that's easy to corrupt — truncate the record value, miss a character, or accidentally create a duplicate record that conflicts with the real one.

DMARC Records — Policy Enforcement

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It specifies what to do with emails that fail both checks and provides a reporting mechanism:

_dmarc.yourdomain.com    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

DMARC policies:

• p=none — Monitor only, no enforcement (good for initial setup)
• p=quarantine — Send failing emails to spam
• p=reject — Reject failing emails entirely

What breaks when DMARC is misconfigured:

• A p=reject policy combined with broken SPF or DKIM causes your own legitimate emails to be rejected
• Removing a DMARC record entirely removes your protection against email spoofing
• An overly strict policy can block legitimate email from third-party senders you've authorised

Why These Records Change Unexpectedly

DNS record changes that break email happen in several ways:

Nameserver migrations — Moving DNS to a new provider (e.g., to Cloudflare) requires manually recreating all records. It's easy to miss TXT records, especially the long DKIM keys, or to get the DKIM selector name wrong.

Accidental deletion — Most DNS dashboards don't require confirmation before deleting records. A misclick in a DNS editor can delete an MX or DKIM record instantly.

Domain transfers — Transferring a domain to a new registrar sometimes involves transferring DNS hosting too. Records can be lost in the process.

Third-party service changes — If you switch email providers (e.g., from Mailgun to SendGrid), you need to update SPF to include the new provider and add new DKIM records for the new provider's selector. If you forget, email from the new provider fails authentication.

DNS hijacking — An attacker who gains access to your DNS management can change MX records to intercept your inbound email. This is less common but highly damaging.

How to Verify Your Records Are Correct

Check MX Records

# Command line
dig MX yourdomain.com

# Or
nslookup -type=MX yourdomain.com

Compare the output to what your email provider specifies. The MX records should match exactly.

Check SPF

dig TXT yourdomain.com | grep spf

Verify the SPF record includes all services that send email on your behalf: your main email provider, any marketing email tool, transactional email service, etc.

Common SPF mistake: Having two SPF records. You can only have one v=spf1 record. Multiple SPF records cause authentication failures. If you need multiple services, combine them into one record:

"v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all"

Check DKIM

# Replace 'google' with your DKIM selector
dig TXT google._domainkey.yourdomain.com

Your email provider's documentation specifies the selector name and the expected public key value. Verify both match.

Check DMARC

dig TXT _dmarc.yourdomain.com

Online tools like MXToolbox and DMARC Analyzer provide a more user-friendly check of all four record types simultaneously.

Setting Up DNS Record Monitoring

Manual checks are useful for diagnosing known problems, but they don't catch unexpected changes. DNS record monitoring continuously watches your records and alerts you the moment something changes or is missing.

Specifically, you want to know:

• If your MX records change or disappear
• If your SPF record is modified or deleted
• If your DKIM record changes (which would invalidate all outgoing email signatures)
• If your DMARC policy changes

Domain Monitor monitors DNS records alongside domain expiry, uptime, and SSL certificates. Configure DNS monitoring for your domain and you'll be alerted to unexpected record changes before they cause noticeable email problems. Create a free account.

For a deeper background on DNS records, see DNS record types explained and ultimate guide to DNS. For Domain Monitor's specific DNS monitoring features, see DNS monitoring is here.

Also in This Series

• What Happens When a Domain Expires? Full Lifecycle Explained
• Domain Grace Period vs Redemption Period vs Pending Delete
• Why Domain Auto-Renew Fails and How to Prevent It
• What Is DNS Propagation and How Long Does It Take?
• A Record vs CNAME vs ALIAS: Which Should You Use?