SPF DKIM and DMARC Explained for Your Own Domain

SPF, DKIM, and DMARC are the three DNS records that tell receiving mail servers whether an email claiming to come from your domain is actually authorized by you. If you want a plain explanation of spf dkim dmarc explained for your own domain, start here: SPF says which servers may send mail for your domain, DKIM adds a cryptographic signature to each message, and DMARC tells receivers what to do when SPF or DKIM fail. Together they stop spammers from forging your address, and they keep your legitimate mail out of the spam folder.

What SPF Actually Checks

SPF, or Sender Policy Framework, is a TXT record published at your domain root. It lists the IP addresses or hostnames that are allowed to send mail for that domain. When a receiving server gets a message, it looks up the envelope sender, which is the address in the MAIL FROM command, not the From: header you see in your client. It then queries your domain for the SPF record and checks whether the connecting IP is in the list.

The record uses a version tag followed by mechanisms and qualifiers. A typical record looks like this:

v=spf1 ip4:192.0.2.10 include:_spf.example.net -all

That record says: allow mail from 192.0.2.10, also allow whatever _spf.example.net says, and reject everything else with the hard fail -all. You can use ~all for soft fail, which marks mail as suspicious but not rejected. The include: mechanism is how you delegate to a third party, like a bulk mail service, without listing every one of their IPs yourself.

To check your current SPF record, use dig on a terminal:

dig TXT example.com +short
"v=spf1 ip4:192.0.2.10 include:_spf.example.net -all"

If the output is empty or shows no v=spf1, you have no SPF record. If it shows multiple SPF records, that is a configuration error, receivers will treat it as a permanent failure.

DKIM Signs the Message Body and Headers

DKIM, or DomainKeys Identified Mail, is a signature that travels inside the email itself. The sending server signs a set of headers and the message body with a private key. The public key is published as a TXT record at a selector name under _domainkey in your domain. The receiver fetches that public key, verifies the signature, and checks that the signature covers the relevant parts of the message.

The signature appears as a DKIM-Signature header in the raw message. It looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=default;
 c=relaxed/relaxed; q=dns/txt; h=from:to:subject:date;
 bh=2jUSO9NtVcHqQ4iKj7xLm8pZ0aBcDeFgHiJkLmNoPqRs=;
 b=dWJhbmdvZW5jcnlwdGVkY29udGVudGhlcmVzb21ldGhpbmd0b2xvbmc=

The d= field is your domain, s= is the selector, and b= is the actual signature. The receiver constructs the DNS query for default._domainkey.example.com and reads the public key from the TXT record. That record typically looks like:

default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

You do not generate this by hand. Your mail server or email service creates the key pair and gives you the public key to publish. What you must verify is that the selector matches what your server uses. Check your outgoing mail headers, find the s= value, then query that selector:

dig TXT default._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

If the query returns nothing, or if the p= value is empty, DKIM is broken. Also check that the d= in the signature matches the domain in your From: header, because receivers will not accept a signature for a different domain.

DMARC Ties SPF and DKIM Together

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is a policy record at _dmarc.example.com. It tells receivers what to do when a message fails both SPF and DKIM. It also asks receivers to send you XML reports about authentication results. The record is a TXT record with tags separated by semicolons.

A minimal DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]

The p= tag is the policy. none means take no action, just report. quarantine means send failing mail to spam. reject means refuse it outright. The rua= tag is the address for aggregate reports. You can also add ruf= for forensic reports, but start with rua only.

DMARC does not replace SPF or DKIM. It uses their results. For a message to pass DMARC, it must pass either SPF with an aligned domain or DKIM with an aligned domain. Alignment means the domain in the From: header must match the domain used in SPF or DKIM. If you send from [email protected] but your SPF record covers example.net, that fails alignment even if SPF itself passes.

To check your DMARC record, run:

dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:[email protected]"

If you see no record, you have no DMARC policy, which means receivers will apply their own default, usually accepting mail that fails authentication but possibly flagging it. If you see p=reject but you have no SPF or DKIM, you will lose legitimate mail, so never set reject before you confirm both other records work.

How to Check All Three at Once

You can test your setup by sending a mail to a test address that shows you the authentication results. Many providers offer this, and you can also read the headers yourself. Look for Authentication-Results headers added by the receiving server. They will show lines like spf=pass, dkim=pass, and dmarc=pass. If any shows fail or permerror, fix that record first.

For a quick command line check, use dig for all three records in one go:

dig TXT example.com +short
dig TXT default._domainkey.example.com +short
dig TXT _dmarc.example.com +short

Compare the output against what your mail server expects. The SPF record must end with -all or ~all, never with a bare include. The DKIM public key must be a complete base64 string. The DMARC record must have a valid p= tag and a reachable rua= address.

Setting Them Up in Order

Do not publish all three at once. Start with SPF, because it is the simplest and has the least risk. Add the record, wait for DNS propagation, then send a test mail and confirm spf=pass. Next add DKIM, generate a key pair with your mail server, publish the public key, and confirm dkim=pass. Only after both pass should you add DMARC with p=none and a reporting address.

Leave DMARC in none for at least a week. Read the aggregate reports you receive. They show you which sources are failing and which IPs are sending mail you did not authorize. When you see no legitimate mail failing, move to p=quarantine. After another week with no problems, move to p=reject. This gradual path protects you from silently losing mail while you learn your own sending patterns.

One more detail: SPF has a limit of ten DNS lookups per record. Every include and every redirect counts, and so do the lookups inside those includes. If you exceed ten, receivers return permerror and your SPF fails. Keep your record short, and if you use a third party, prefer their include over listing many IPs yourself.

Your next step is to run the three dig commands above on your own domain right now. Write down what each returns, fix the missing records one at a time, and send a test message to a mailbox you control. Read the Authentication-Results header in that message. When all three show pass, you are done, and your outgoing mail will stop being mistaken for spam.