How to Set Up DMARC for Small Business

Why DMARC Matters for Small Business Email

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is a DNS record that tells receiving mail servers what to do with messages claiming to come from your domain.

Spoofing is not a big-company problem. A domain with four mailboxes is exactly as easy to forge as one with four thousand, and in some ways it is a better target, because nobody at a four-person company is reading authentication logs. Without DMARC you will not even find out it happened.

The setup is one TXT record. Writing it takes two minutes. Knowing what to put in it is the part that takes a week.

Three things change once the record is live. Forged mail sent in your name starts getting filtered or refused instead of landing in a customer's inbox. Your own mail stops being filtered as unauthenticated, which Gmail and Yahoo now refuse to accept from bulk senders. That removes a reason to block you; it does not prove anyone wanted the message. And you begin getting daily reports naming every server that sends mail as you, which is the part most people underestimate and the part I find most useful.

The FTC's guidance on email authentication for small businesses makes the same argument from the consumer side: authentication is how you stop fraud from being committed under your name. The deliverability gain is a side effect.

Identify Your Email Senders Before You Start

Before you write a policy, list every service that sends email with your domain in the From address. Skipping this is why a policy that looked safe on day one starts bouncing invoices and password resets on day thirty.

Start with the places money and account access actually flow through. For most small businesses the list looks like this:

For each row, record the sending domain or IP range, whether the vendor signs with SPF, DKIM, or both, and the exact From address a recipient sees.

To find the senders you have forgotten about, search all mail, not just Sent, for from:yourdomain.com over the last 90 days (receipts and notifications that vendors sent in your name often copy you), then read your existing SPF record and look up anything in it you cannot immediately name.

Check alignment, not only authentication. This trips people up constantly. SPF can pass on the envelope sender while DMARC still fails, because DMARC asks whether the visible From domain lines up with the SPF or DKIM domain.

Put the list in a spreadsheet with columns for vendor, sending domain, SPF, DKIM, alignment status, and owner. You will use it when you set up SPF and DKIM, which both come before DMARC, and again when your first reports arrive.

If you use SEMAOS for broadcasts and sequences, a custom sending domain means adding the ownership TXT record, three DKIM CNAMEs, and the MX and SPF records on mail that SEMAOS shows you. What the custom sending domain setup includes is listed on the features page.

DMARC Record Example and Basic Syntax

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com.

A basic one looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Each tag does a specific job:

Read aloud, that record says: I use DMARC, do not enforce anything yet, and send the daily aggregate reports here. It is the safe opening move, because you get the data before you get the risk.

A stricter record:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com

That one asks receivers to quarantine every message that fails. In practice, quarantine means the spam folder.

The strictest policy is p=reject, which asks receivers to refuse the message outright. Do not go near it until every legitimate sender passes.

DMARC.org's protocol overview walks through how receivers match your domain against SPF and DKIM signatures. Alignment is the part people get wrong, so read it before you tighten anything.

DMARC Policy: p=none vs quarantine vs reject

Your policy tag tells receivers what to do when a message fails authentication.

There are three values, p=none, p=quarantine, and p=reject, and the right one depends entirely on how sure you are about your sender inventory.

p=none is monitoring. Receivers deliver as usual and send you reports anyway. Start here. You find out what is actually happening on your domain, which is almost always more interesting than what you assumed.

p=quarantine is soft enforcement. Failing messages go to spam rather than the inbox. If you have misconfigured a sender, the customer can still dig the message out of their junk folder, which is the whole reason this middle setting exists.

p=reject is hard enforcement. The message is refused and never arrives, and nobody emails you to say so. Use it only when the reports have been clean for a while.

Add Your DMARC Record at Your DNS Host

Your DNS host is wherever you manage the domain's records: GoDaddy, Namecheap, Route 53, Cloudflare, or your web host. Log in and look for something called DNS Records, DNS Management, or Advanced Settings.

You are creating one TXT record. The host or name field gets _dmarc, the value field gets v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com, and the TTL can stay at 3600 or whatever the default is.

Where that form lives differs by host. On GoDaddy:

1. Go to your domain settings
2. Click "Manage DNS"
3. Click "Add" next to TXT Records
4. Enter the host and value above
5. Click "Save"

Namecheap buries it one level deeper. Click "Manage" next to the domain, open the "Advanced DNS" tab, click "Add New Record," choose "TXT Record" from the type dropdown, fill in the host and value, then click the checkmark at the end of the row to save, which is easy to miss. Cloudflare is the quickest of the three: open the domain's DNS settings, click "Add Record," pick "TXT," enter the host and value, and save.

If none of those screens look familiar, search your host's name plus "add TXT record," or ask their support. Save the record, then leave it alone for a day.

DMARC Record Propagation Time and Verification

DNS changes are not instant. Most DMARC records propagate within 24 hours and some take up to 48, and until they do, receivers behave as though you never published anything. Check with MXToolbox or Google Admin Toolbox: enter the domain and the tool shows the record once it is live.

If nothing appears after a day, work through the obvious causes. Check that you added the record at the host that actually serves your domain's DNS, that the host name is _dmarc and not _dmarc.yourdomain.com duplicated, that the value has no typos, and that you clicked save. Still nothing? Contact your DNS host's support team.

Use a DMARC DNS Record Checker

A checker confirms that the record is published and parseable. What it will not tell you is whether your mail passes authentication. It only reads the record, so a green result means the syntax is valid, not that your email is safe.

Popular checkers:

• MXToolbox DMARC Check
• Google Admin Toolbox
• dmarcian's DMARC Inspector

Enter your domain and run the check. A valid record shows a pass or a green checkmark. If it fails, the tool usually names the problem for you, and it is nearly always a missing semicolon between tags, a typo in the rua address, or a record that simply has not published yet. Fix it and re-check.

The three standards divide the work. SPF says which servers may send for your domain, DKIM signs the message so a receiver can verify it was not altered, and DMARC decides what happens when the visible From domain does not align with either.

Reading Your DMARC Reports and Next Steps

Aggregate reports land at the address in your rua tag, usually once a day, usually overnight. They arrive as gzipped XML and they are unreadable at a glance, which is where most people give up.

Work the buckets in that order. Sources that are known and aligned need nothing from you. Sources that are known and failing are the ones that will break real mail the moment you move to p=quarantine, so they come first.

Here is the routine I would give a nontechnical owner:

1. Open the report in a tool that renders the XML as a table. Most free ones take an upload and show source IP, message count, and pass or fail per method.
2. Sort by message count, highest first. The top few sources usually account for nearly all your mail.
3. Match each source IP against your inventory. If it matches a vendor, confirm SPF and DKIM both pass. If one of them fails, that is a configuration fix, not a mystery.
4. For anything unmatched, look up the IP's organization with WHOIS. A cloud provider you have never used is a red flag. A vendor you forgot about is just a fix.
5. Log the date, source, result, and action, one line per source. That log is what justifies raising the policy later.

Before moving from p=none to p=quarantine, all of the following should be true:

• Every source sending more than a handful of messages a day is either on your inventory or identified as spoofing.
• Every known sender passes both SPF and DKIM, or you have written down why it cannot and accepted that risk.
• You have at least two weeks of reports with no unexplained legitimate failures.

If one of them is not true, stay at p=none and fix the sender.

Once you are at p=quarantine, read the reports weekly. Watch for a known sender that suddenly starts failing, which usually means the vendor changed infrastructure. Watch for new unknown sources. And watch for legitimate volume quietly dropping, which means a sender stopped working and nobody noticed.

The bar for p=reject is higher. Every legitimate sender must pass alignment, and you want 30 days at p=quarantine with nothing legitimate failing before you make the change.

If you use SEMAOS for broadcasts and sequences, platform sends track opens and clicks, and your reports will show those sends passing once your custom sending domain records are live. How platform sending and mailbox sending differ is covered on the features page.

FAQ