How much of the email your organization sent this month actually arrived, and how would you know? Filtered mail produces no bounce and no error. The invoice, the receipt, the volunteer confirmation simply lands in a spam folder or nowhere, and the only evidence on your side is a slow, puzzling quiet: fewer replies, an unpaid invoice, a donor who says "I never got it." Email is the one system in your stack where total failure looks exactly like success. Everything sends. The progress bar completes.
The purpose of this post is to explain the three Domain Name System (DNS) records that decide whether your mail arrives, without fear and without an IT department. They matter twice in Security Month. First, the major mailbox providers now require authentication from senders, and unauthenticated mail is increasingly filtered by default. Second, the same records that get your mail delivered make your domain far harder to impersonate in the phishing messages Tuesday's post and the October "Someone Clicked the Link" post described. By the end you should be able to read your own records, know what order to set them up in, and understand why the last step is measured in weeks rather than minutes.
One metaphor for three records
Think of every email your domain sends as a courier arriving at a receiving mailroom. For years, any courier anywhere could claim to carry mail from your domain, and the mailroom guessed at legitimacy. The three records end the guessing.
SPF (Sender Policy Framework) is the approved-courier list you publish. It is a TXT record in your DNS naming the servers authorized to send mail for your domain, so the mailroom can check each arrival against the list.
DKIM (DomainKeys Identified Mail) is the tamper-evident seal. Your mail provider signs each message cryptographically, and a key published in your DNS lets the mailroom confirm the seal is yours and unbroken.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the standing instruction card you leave with the mailroom. It says what to do with a courier who fails the checks, deliver anyway, send to spam, or reject at the door, and it names a return address where mailrooms send reports of every courier claiming your name.
Three records, one job: proving your mail is yours, so the receiving side can stop guessing. All three live in the DNS directory that Episode 4 of the podcast taught you to read, and the only technical skill involved is adding a TXT record.
Why it is also a security control
Phishing works by impersonation, and your organization's name is a trust asset to its own donors, customers, and volunteers. Before DMARC, anyone could send "from" your domain, and the recipients' filters could only guess. With DMARC at its strictest setting, mail claiming your name and failing your checks dies at the mailroom door, and the fake renewal notice wearing your nonprofit's name never reaches the donor it targeted. Small organizations rarely think of themselves as impersonation targets. The reports from the first month usually correct that impression.
The setup order
The sequence matters, and it begins with the step organizations skip and regret.
List every service that sends email as your domain. The list runs longer than your mailboxes. The website's contact form notifications send as your domain. So does the newsletter platform, the donation or store receipts, and the booking tool. Chapter 2's inventory and a look at your existing TXT records will surface most of them; a month of paying attention surfaces the rest. Every sender missing from this list will fail authentication later, and the failure will look like your contact form going quiet.
Publish one SPF record. Exactly one. Multiple SPF records break authentication outright, which is a common finding on domains where several vendors each added their own. Build a single TXT record that includes every service on the list. For a Google Workspace organization the pattern begins v=spf1 include:_spf.google.com ~all, with each additional service's documented include inserted before the ~all.
Enable DKIM in each sending service. Search each service's help for "DKIM," turn on signing, copy the key it provides, and publish it as the TXT record it specifies. Check the service off on the list.
Publish DMARC gently. The starting record is v=DMARC1; p=none; rua=mailto: followed by a reporting address you control. The policy "none" enforces nothing yet. It begins mailing you reports of who is sending as your domain, which is the entire point of starting there.
Verify. Paste the domain into MXToolbox's free SPF, DKIM, and DMARC checkers and confirm all three pass before going further.
Reading the reports without dread
The first DMARC report puzzles everyone. It arrives as a machine-formatted attachment, aggregated by the receiving providers, and read raw it is about as friendly as a tax form. Route the reports through a free reader such as Learn DMARC or dmarcian's tools, which render them as plain tables, and read the table weekly during the monitoring period.
You are looking for two patterns. Your own services, the mailboxes, the newsletter platform, the form notifications, should appear as passing; any of them failing means an SPF include or a DKIM key is missing, and the report has just found the gap for you. Strangers failing, unfamiliar servers in unfamiliar countries sending as your domain, call for no alarm. Those are the impersonation attempts that were always happening, now visible. When the table turns boring, everything yours passing and everything else failing, you have the signal you were waiting for.
The tightening schedule
The instruction card tightens on a schedule, and the schedule is what beginners must not skip. Run at p=none for four to eight weeks, reading the reports, until every legitimate sender passes and the only failures are strangers. Move to p=quarantine, which sends failures to spam, and watch again. Move to p=reject, the destination, only when the reports have stayed clean for a sustained stretch at quarantine.
Flipping to reject on day one is how organizations block their own contact form on a Friday afternoon. The progression exists because only the reports can prove the courier list is complete, and confidence is not evidence. Google Postmaster Tools, also free, adds the receiving-side view of your domain's reputation once your volume justifies it.
The standing rule
Authentication drifts through additions, not decay. The day a new service that sends email is adopted, its SPF include and DKIM key go in, the same day, and the rule belongs in the decisions log where the next web manager will find it. Re-verify with MXToolbox annually from the maintenance calendar. Next week's Episode 8 companion covers where that calendar lives.
What is at stake
The mission stake is intimacy at scale. Email is where your organization speaks to people one at a time: the receipt that says the donation landed, the reply that solves the problem, the letter that keeps a relationship warm. Every message that silently fails to arrive is a small breach of faith the organization never knows it committed, and every forged message that arrives wearing your name spends trust you did not agree to spend. An afternoon on three records, and a few weeks of reading boring reports, is what it costs to make the channel worthy of what travels through it.
Get the worksheet. The M10.1 Email Authentication Setup Worksheet walks the full sequence: the sending-service inventory, the single SPF record, DKIM per service, DMARC at none with reporting, MXToolbox verification, and the dated tightening schedule, with the Offboarding Runbook Card on the back. It is free with a Web Managers account at https://webmanagers.com/register, and it arrives with the weekly Web Managers letter.