Can someone send email as your domain right now?

Yes. Unless the DMARC record on your domain says p=quarantine or p=reject, anyone can type your domain into the From: line of an email, attach an invoice with your logo, and most receiving mail servers will put it in your customer’s inbox as if you’d sent it. That’s what happened to the customer who rang about a bill you never raised. Nobody broke into your mailbox to do it, and the check that tells you whether it can happen again takes under a minute.

Where the answer for your domain is written down

The answer is one DNS record, a TXT record at _dmarc. in front of your domain. Receiving servers look it up for each message that claims to come from you, and you can look it up the same way:

dig +short TXT _dmarc.example.com

Three things can come back. If nothing comes back, there’s no record, so anyone can send as your domain and no receiver will report it to you. If you get "v=DMARC1; p=none; rua=mailto:[email protected]", they still can, though receivers deliver the forged message and email you a daily summary about it.

If you get "v=DMARC1; p=reject; rua=mailto:[email protected]", a receiver that checks DMARC refuses mail claiming to be from the bare domain during delivery, before anyone sees it.

If you’d rather see the same verdict without a terminal, run the free scan on your domain and read the DMARC field, which shows absent, none, quarantine or reject.

Most domains answer yes

Of the 316,600,902 domains carrying a grade in the September 2026 census (graded plus dead), 280,002,876 have no enforcing DMARC policy. Only 16,714,260 (5.3%) of the domains where the DMARC check ran are at p=reject. So if your record came back empty or at p=none, you’re in the same position as most of the registered internet, and the three records below get you out of it.

Those counts describe records: the receivers wouldn’t stop a forgery, whether or not anyone is sending as those domains today. For your domain, the fact that a customer already holds a forged invoice means somebody has tried, and the same person can try again tomorrow with the same tools until the record changes.

How the forged invoice was sent

Email has two From addresses. The one your customer saw is the From: header, and that’s plain text the sender types. The other is the envelope sender, MAIL FROM, which the sending server hands over before the message body and which the reader doesn’t see. A forger sets the envelope to a domain they control and the header to yours:

MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: Accounts <[email protected]>
To: [email protected]
Subject: Invoice 2417 now overdue

To do this they needed your domain name, one customer address (from your website, say, or a signature in a forwarded thread), and any server prepared to send mail. They didn’t need your password, your mailbox, your website login or your DNS console. Resetting passwords after the customer’s call did no harm, and it also changed nothing here, because the message went nowhere near your account.

SPF checks the envelope domain, which belongs to the forger, so SPF can pass on their own domain. DKIM signs with whatever key the sending server holds, so either there’s no signature or there’s one for their domain. DMARC is the only check that reads the From: header your customer saw and asks whether SPF or DKIM passed for that domain. With no DMARC record, the receiver has no instruction and delivers.

The line in the header that proves it

Ask the customer to forward the message as an attachment, or to use “show original” and paste what they see, then look for the Authentication-Results: header near the top. On a forged invoice sent to a domain with no policy it reads something like this:

Authentication-Results: mx.customer.example;
       spf=pass (sender IP is 203.0.113.7) smtp.mailfrom=rented-server.example;
       dkim=none (message not signed) header.d=none;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Read the last line. header.from=example.com is your domain. dmarc=fail means neither SPF nor DKIM passed for it. p=NONE is the policy the receiver found, and dis=NONE records that it did nothing about the failure. If your record is absent rather than p=none, the same line reads dmarc=none and the receiver didn’t even try.

Either way the customer’s server did what your DNS told it to do. Once you change the record, a receiver at quarantine writes dis=QUARANTINE and files the message as junk, and a receiver at reject refuses it during delivery, so no header gets written at all.

Three records, published in this order

A DMARC policy at reject applies to your own mail too, so it goes last. Publish it before your real senders are listed and your own invoices will bounce.

SPF: list the servers allowed to send as you

SPF is a TXT record at the domain itself. Put in it each service that sends mail with your domain on it: your mailbox provider, the invoicing app, the newsletter tool, the website’s contact form. A finished record looks like this:

v=spf1 include:_spf.mailhost.example include:mail.invoicing.example -all

-all at the end tells receivers that anything not listed fails. If you’re unsure whether you’ve found each sender, publish with ~all first and move to -all once the DMARC reports (below) show nothing legitimate failing. The SPF piece walks through each mechanism and the ten-lookup limit that silently breaks long records.

DKIM: sign what you send

DKIM is a signature your sending servers add and a public key you publish so receivers can verify it. Each provider that sends for you has a switch for it in its admin console and gives you a record to publish at selector._domainkey.example.com; the selector name is theirs. Turn it on for each sender, publish the records, then confirm each one:

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

A p= value followed by a long block of characters means the key is live. The DKIM piece covers what a signature contains and why a key can exist and still fail to align with your domain.

DMARC: start at none, finish at reject

Publish this TXT record at _dmarc.example.com:

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

Within a day or two, receivers start sending reports to that address, one per receiver per day, listing each source that sent mail as your domain and whether it passed. Read them for two weeks. Any legitimate source that’s failing (the invoicing app you forgot, the office printer that emails scans) gets added to SPF or given a DKIM key. Sources you don’t recognise are the forgers, and there’s nothing to fix on your side for those; the policy will deal with them.

When the reports show your real senders passing, change p=none to p=quarantine, wait another week, then p=reject. Each step is one edit to the same record. The DMARC piece explains each tag in that record, including sp= for subdomains and pct= for a staged rollout, and what the daily reports contain.

If the domain sends no mail at all

The spare you registered to protect the name, or an old brand you’ve retired, can go straight to reject on day one, because there’s no legitimate mail to protect:

v=spf1 -all
v=DMARC1; p=reject; rua=mailto:[email protected]

The first record says no server may send as this domain. The second says refuse anything that tries. A forger who moves from your main domain to a spare one after you lock the first gets refused there as well.

What to tell the customer this week

Tell them the invoice didn’t come from you, that your bank details haven’t changed, and to confirm any change of details by phone on a number they already had before paying anything. Ask them to forward the message as an attachment so you have the headers. If they’ve already paid, their bank needs to hear it today, since recalls get harder with each day that passes.

Once p=reject is live, run the scan again and confirm the DMARC field reads reject and the SPF field shows -all. Run it again whenever you change mail provider or add an invoicing tool, because a new sender that isn’t in SPF or signing with DKIM is the next call from a customer, this time about your own invoice failing to arrive.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.