DMARC in four weeks: reach p=reject without blocking your own mail

What DMARC is and where hotels stand

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a line of text in your domain's DNS, the internet's public directory for domain names. It tells receiving mail servers what to do with a message that uses your domain in the From address but cannot prove it came from you. In our hotel email index of 732 Flemish hotel domains, measured on 28 September 2026, 52.7% had no valid DMARC record and 34.3% had p=none, which asks receivers to take no action. That leaves 87.0% with no instruction to block a forged email. Only 7.2% were at p=quarantine and 5.7% at p=reject, and 157 of the 251 domains at p=none had not asked for reports either. The Centre for Cybersecurity Belgium and DNS Belgium name SPF, DKIM and DMARC in their joint guidelines against email fraud (DNS Belgium). Our email check shows where your domain stands and explains how spoofing works.

Week 1: list every sender and clean up SPF

SPF (Sender Policy Framework) is a DNS record listing the services allowed to send mail for your domain. DKIM (DomainKeys Identified Mail) puts a digital signature on each message, checked against a public key in your DNS. A message passes DMARC when SPF or DKIM passes for a domain that matches the one in the From address your guest sees. That match is called alignment (RFC 9989, section 4.4).

Write down everything that sends email with your domain in the From address:

• the mailboxes in Microsoft 365 or Google Workspace
• your booking engine
• your property management or front-desk system
• your invoicing or accounting tool
• your newsletter tool
• the website contact form, a scanner that emails documents, alarm or camera alerts
• an agency or bookkeeper that sends on your behalf

Ask each supplier which DNS records they need for SPF and DKIM.

An SPF record is a TXT record starting with v=spf1, and each outside service is usually added with an include: entry, such as include:spf.protection.outlook.com for Microsoft 365. Your domain may have only one SPF record; two make SPF fail with a permanent error (RFC 7208, section 4.5). SPF also allows at most 10 DNS lookups (RFC 7208, section 4.6.4). Each include costs at least one lookup, and the includes nested inside it count as well. A record over the limit fails with a permanent error (Microsoft). Remove services you no longer use. Microsoft recommends sending bulk mail such as a newsletter from a subdomain like news.yourhotel.be, which has its own SPF record and its own 10 lookups.

Week 2: DKIM for every sender, then DMARC at p=none

Microsoft 365 does not sign mail from your own domain with DKIM until you set it up. The Defender portal gives you two CNAME records (selector1._domainkey and selector2._domainkey) to create at your DNS host, and then you switch signing on (Microsoft). A CNAME record points one name to another, so the provider keeps the key and can replace it. In Google Workspace you generate a key in the Admin console (2048-bit if your DNS host accepts it), publish the TXT record it shows and click Start authentication. Google says DKIM can take up to 48 hours to start working (Google).

Do the same for every outside sender. Many ask for CNAME records under _domainkey, which lets them rotate the key without asking you (M3AAWG, section 3.1.3). Deleting a CNAME later withdraws that sender's permission. A service that signs only with its own domain and uses its own return address will never align. Ask whether it can sign with your domain, or use a return address on your domain (often called a custom MAIL FROM).

Google advises waiting 48 hours after SPF and DKIM before publishing DMARC (Google). Then add a TXT record named _dmarc with this value:

v=DMARC1; p=none; rua=mailto:dmarc@yourhotel.be

With p=none, delivery does not change. The rua tag asks receivers to send aggregate reports, daily summaries of who sent mail in your name, so use a dedicated mailbox for them. If that mailbox is in another domain, the other domain must publish a record allowing it (RFC 9990, section 4). Set the TTL (time to live, how long other servers may cache the record) to one hour, so changes and a rollback take effect quickly.

Since February 2024, Gmail has required senders of more than 5,000 messages a day to personal Gmail addresses to have SPF, DKIM, a DMARC record (p=none is enough), a From domain that aligns with SPF or DKIM, and one-click unsubscribe (Google). Yahoo sets the same rules for bulk senders but gives no number (Yahoo, FAQ). Since 5 May 2025, Microsoft has required SPF, DKIM and aligned DMARC from senders of more than 5,000 messages a day to Outlook.com, Hotmail and Live addresses, and rejects failing mail with error 550 5.7.515 (Microsoft). A newsletter to your whole guest list can cross that line.

Weeks 2 and 3: read the reports and fix what fails

Reports arrive as an XML file, usually compressed, attached to an email, usually daily from each large mail provider. Each row shows a sending IP address, a message count, whether SPF and DKIM passed, and whether they aligned with your domain (RFC 9990, section 3.1). Once unzipped, the file opens in a browser, and the free open-source command-line tool parsedmarc can turn many reports into one table (a CSV file).

Go through the rows one sender at a time (Microsoft):

• A service you know passes SPF or DKIM and still fails DMARC. It signs or sends with its own domain; set up DKIM with your domain there.
• A service you know fails both. It is missing from SPF and has no DKIM; add both.
• A sending IP address you do not recognise fails everything. This is often someone forging your domain, and it is the mail that quarantine and reject are meant to stop.
• Forwarded mail fails SPF, because the forwarding server is not in your record. DKIM usually survives forwarding, one more reason for every sender to sign.

You are ready for week 4 when every service you use shows aligned DKIM or SPF in at least a week of reports. The standard warns this can take many months when some mail goes out only now and then (RFC 9989, section 5.1.7). If invoices go out monthly, wait until you have seen that run pass, even if the plan stretches.

Week 4: quarantine, then reject

Change the record to p=quarantine. Failing mail then usually goes to the spam folder. Watch the reports for a few days and ask reception whether guests mention missing confirmations. When both are clean, change to p=reject, which asks receivers to refuse failing mail. RFC 9989 is more cautious for domains whose users post to mailing lists: it advises at least a month at p=none and as long again at p=quarantine before p=reject (section 7.4). If your staff use mailing lists, take that slower route. You can also end SPF with -all instead of ~all now, as Microsoft recommends once DKIM and DMARC are in place.

RFC 9989, published in May 2026, replaced RFC 7489 and removed the pct tag, which applied a policy to a percentage of mail. It added a testing tag: with t=y, receivers are asked to apply one level less, so p=reject with t=y is handled as quarantine (section 4.7 and appendix A.6). Receivers still on the old standard ignore tags they do not know and apply the full policy, so use t=y only once the reports are clean.

What can go wrong, and how to roll back

• A sender you missed, such as a tool that mails once a quarter, lands in spam or bounces. Add it to SPF and DKIM.
• Mail that a guest's address forwards on, or that passes through a mailing list, can fail DMARC. RFC 9989 discusses these cases and says a domain at p=reject must sign its mail with DKIM, because SPF alone breaks when mail is forwarded (section 7.4).
• A typing mistake can make receivers report an error or ignore part of the record, and when a domain has two DMARC records, receivers discard both (Microsoft, RFC 9989, section 4.10).
• A new booking engine or newsletter tool that sends before its SPF and DKIM are set up.

Rolling back is one DNS edit: set p=reject back to p=quarantine or p=none. With a one-hour TTL, receivers pick up the change within about an hour. Keep the rua address at every stage so the reports show what happened.

What DMARC does not stop

DMARC protects your own domain name and its subdomains. A look-alike domain registered by someone else, with an extra word or one letter changed, can pass every check for itself. Our look-alike check shows which close variants of your domain are in use. DMARC also cannot see that a real mailbox was taken over, because mail from a hacked account really comes from your systems. Two-step login on every mailbox makes that much harder, and our article on fake Booking.com payment requests covers what reception can do.

Checklist

1. List every service that sends with your domain.
2. One SPF record, under 10 lookups, every sender included.
3. DKIM on in Microsoft 365 or Google Workspace and at every outside sender.
4. DMARC at p=none, rua to a dedicated mailbox, one-hour TTL.
5. Reports read until every known sender aligns for a full week.
6. p=quarantine for a few days, then p=reject, and SPF ending in -all.
7. The email check run again after every change.