← Resources

SPF, DKIM and DMARC Explained: How to Check Your Email DNS Records

Ekim 4, 2026 · IpDnsHub · 4 views ·
email dns security

Why Email Authentication Matters

Email was designed without any way to prove who sent a message. Anyone can put any address in the “From” line. SPF, DKIM and DMARC were added over the years to fix this, and today large mailbox providers rely on them heavily. Since 2024, Gmail and Yahoo require bulk senders to have all three in place, and messages from domains without proper authentication are much more likely to be rejected or filtered as spam.

All three are published as DNS TXT records, so you can inspect them with our DNS Record Lookup or get an overview with the DNS Report.

SPF: Which Servers May Send for Your Domain

Sender Policy Framework (SPF) is a TXT record on your domain that lists the servers allowed to send mail for it. A typical record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all
  • include: adds the servers of a provider (here Google Workspace and SendGrid).
  • -all says that all other servers are not allowed. ~all (“soft fail”) is a softer version often used during setup.

Common SPF Mistakes

  • Two SPF records: a domain must have only one. Merge them into a single record.
  • Too many DNS lookups: SPF allows at most 10 DNS lookups (each include, a, mx and similar mechanism counts). Exceeding the limit makes SPF fail.
  • Forgetting a service: newsletters, CRMs, invoicing tools and website contact forms all send mail. Each must be covered.

DKIM: A Signature on Every Message

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to each outgoing message. The receiving server fetches your public key from DNS and checks that the message was signed by you and was not changed in transit.

The public key is published under a selector, for example google._domainkey.example.com. Your email provider tells you which selector and value to publish. Because selectors are chosen by the provider, you need to know the selector name to look the record up.

Unlike SPF, DKIM survives forwarding, because the signature travels with the message.

DMARC: The Policy That Ties It Together

DMARC tells receiving servers what to do when a message fails authentication, and where to send reports. It lives at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:[email protected]
  • p=none – monitor only; deliver as usual and send reports.
  • p=quarantine – treat failing messages as suspicious (usually the spam folder).
  • p=reject – refuse failing messages.

DMARC also requires alignment: the domain in the visible From address must match the domain that passed SPF or DKIM. This is what actually stops someone from sending mail that appears to come from your domain.

A Safe Rollout Plan

  1. Publish SPF and enable DKIM for every service that sends mail for you.
  2. Publish DMARC with p=none and a reporting address.
  3. Read the reports for a few weeks and fix any legitimate source that fails.
  4. Move to p=quarantine, then to p=reject.

Checking Your Setup

  • Look up the TXT records of your domain and of _dmarc.yourdomain with the DNS Record Lookup.
  • Check that your MX records point to the right mail provider.
  • Make sure your sending server has a matching reverse DNS (PTR) record — see our guide on reverse DNS and PTR records.
  • If mail is still rejected, check whether your server’s IP address is listed on a blacklist with the Spam Database Lookup.