In this guide 6 sections
Three records protect your mail. SPF lists the servers allowed to send, DKIM adds a signature proving a message was not altered, and DMARC tells receivers what to do when either check fails. Add them in that order, with the business holding the DNS login, so that invoices and OTP mails stop landing in spam.
What each record proves
A receiving mail server asks three questions. Was this sender allowed to use the domain, was the message tampered with in transit, and what should happen if either answer is no?
SPF answers the first, as a TXT record at your domain that names approved senders such as your mail host and your invoicing software. DKIM answers the second with a cryptographic signature that the receiver checks against a public key published in DNS, so edits in transit show up.
DMARC answers the third question and also demands that the visible From address match the domain that passed SPF or DKIM, a rule called alignment. Alignment is the part people miss. A forwarded invoice or a newsletter sent from a third-party tool often fails it, even when the message looks perfectly ordinary to the recipient.
- SPF: which servers may send
- DKIM: the message is genuine and unaltered
- DMARC: the policy, plus reports back to you
The order to add them
Start with an inventory. List every system that sends mail as your domain, from staff mailboxes and the billing app to the website contact form, the OTP service and the newsletter tool. A missed sender is the usual culprit.
SPF goes in first. Then enable DKIM in each sending service, which hands you a selector name and a public key to paste into DNS as a TXT or CNAME record.
Publish DMARC last, in monitoring mode. The p=none policy changes nothing for delivery but starts aggregate reports arriving, and you should read them for two or three weeks before tightening anything.
Who must hold the DNS login
DNS often sits with whoever built the website, a freelancer or a vanished agency, so when billing software changes its sending server nobody can edit the SPF record.
Put the registrar and DNS account under a company email, with two-factor sign-in and at least two named people, one of whom is the owner or operations head.
Developers then request changes and your side approves them, a small habit that prevents the scramble when invoices stop arriving in customers’ inboxes the week before month-end. The habit costs nothing.
A bad sender or a broken record?
Open the spam-filed message. View its full headers and find the Authentication-Results line, where spf=, dkim= and dmarc= each show pass or fail, and a fail on one points to the culprit.
Broken records fail everything from one tool. A bad sender, meaning one with a poor reputation, fails some messages and passes others, often because of the content or the sending volume.
Common faults are two separate SPF records on one domain, a missing include for the newsletter tool, or a DKIM key pasted with a stray space or line break. Fix these before blaming the provider.
- Two SPF records on one domain
- A sender missing from SPF
- A DKIM selector published under the wrong name
- From address that does not match the signing domain
Tightening the policy safely
Once the aggregate reports show every legitimate sender passing, move DMARC to quarantine, which sends suspect mail to the spam folder instead of the inbox. After a quiet month, consider reject, which asks receivers to drop failing mail instead of filing it, but only if every report still looks clean.
Never rush this step. A forgotten sender, perhaps a warehouse system that mails dispatch notes, starts bouncing the day you tighten, so test before every change and keep the old text for rollback.
Send a test from every system after each change, note which headers show pass, and keep the results on one sheet beside the date. Reread the sheet before the next tightening step, and ask each system owner to confirm that nothing else sends mail on the domain.
Email sender inventory sheet
One row per sender. Columns record the system, the sending address, whether SPF includes it, the DKIM selector, the date DKIM was verified and the named owner. A box at the foot tracks the DMARC policy stage, whether none, quarantine or reject, together with the date of the next report review.
Open a blank worksheet to printQuestions owners ask
Do we need all three records?
For mail sent by software, yes, because major receivers increasingly expect authentication and each record covers a different gap, such as tampering, forged senders or missing policy. Skip one and a gap stays open.
Will DMARC stop our mail from arriving?
Not in monitoring mode. Only a quarantine or reject policy affects delivery, and only for messages that fail the checks, so legitimate mail is safe once every sender is listed.
Can one domain have several DKIM keys?
Yes. Each sending service uses its own selector name, so the billing app, the newsletter tool and the mailbox host can all publish keys side by side without clashing. Add the selector name to your sheet.