Is someone sending fake email in your name? Protect your domain with SPF, DKIM and DMARC

Today anyone can send an email that shows your domain in the "From" line, with no permission required. The core email protocol (SMTP) never verifies who the sender really is, so a scammer can impersonate billing@yourcompany.com and send a fake invoice to your customer. SPF, DKIM and DMARC are the three DNS records that close this gap. SPF lists the servers authorized to send mail for your domain, DKIM seals every message with a cryptographic signature, and DMARC tells receiving servers what to do with messages that fail those two checks: monitor, quarantine or reject. Set up correctly, the three of them keep forged mail sent in your name out of the recipient's inbox entirely.

These records moved from "nice to have" to mandatory a while ago. On 1 February 2024, Google and Yahoo began requiring bulk senders (those sending roughly 5,000 or more messages a day to personal accounts) to have SPF, DKIM and a DMARC record set to at least p=none. Microsoft adopted the same 5,000-per-day threshold for Outlook.com and Hotmail, enforced from 5 May 2025; non-compliant senders first saw their mail routed to junk, then rejected outright at the server. If you send any marketing or bulk notification from your domain, your messages may simply not arrive without these three records.

SPF: who is allowed to send?

SPF (Sender Policy Framework) lists, in a DNS TXT record, which servers are authorized to send email for your domain. The receiving server compares the IP the message came from against that list. Say you send through both Google Workspace and your invoicing software; your SPF record should authorize only those two. There is one technical limit worth knowing: SPF evaluation may not exceed 10 DNS lookups. Adding an include for every new service fills that budget quickly and can invalidate the whole record, so removing services you no longer use matters as much as adding new ones.

DKIM: was the message altered in transit?

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature, generated with a private key, to every message you send. The public key needed to verify it is published in DNS. By checking the signature, the receiving server confirms two things: the message really came from a system you authorized, and its content was not changed along the way. A 2048-bit key is today's standard; 1024-bit is still accepted but now considered weak. Rotating your signing keys once a year is a good habit.

DMARC: what happens when a check fails?

DMARC (Domain-based Message Authentication, Reporting and Conformance) does two jobs at once. The first is alignment: it requires that the domain which passed SPF or DKIM matches the domain the recipient actually sees in the "From" field. That stops an attacker from hiding behind a valid SPF record on their own domain while impersonating yours. The second is policy: you decide what happens to messages that fail. There are three settings: p=none (do nothing, just report), p=quarantine (send to junk) and p=reject (block completely). DMARC also reports back to you; the address you name in the rua tag receives daily summaries showing who is trying to send mail in your name, and from where.

The right order to roll it out

The most common mistake is starting straight at p=reject. Do that before SPF and DKIM are properly configured for every legitimate service (your invoicing system, HR software, marketing tool) and their mail gets rejected too. The safe path is gradual:

• Start at p=none. It blocks nothing and only gathers reports. The goal is to see which systems really send mail as your domain.
• Read the reports for a few weeks. The rua data reveals sending services you forgot about or never knew existed.
• Fix the legitimate sources. Configure SPF and DKIM correctly for each valid service and make sure they align.
• Move to p=quarantine. Suspicious mail drops to junk; watch for any legitimate message still being caught by mistake.
• Finish at p=reject. Only once all your legitimate traffic passes cleanly do you switch on full protection.

What DMARC does not protect

An honest caveat: DMARC only stops impersonation of your exact domain. It protects yourcompany.com, but it does nothing against lookalike domains such as yourcompany-support.com or a version with a swapped character your eye skips over. It also does not stop an attacker who sends from their own address but sets the display name to "Yourcompany Billing", because technically no spoofing has occurred. Email authentication should not stand alone; treat it alongside employee awareness and registering the obvious lookalike domains yourself before someone else does.

Pushing DMARC up to quarantine or reject unlocks one more thing: BIMI. This standard lets you display your brand logo next to the sender name in email clients that support it. It looks like a small visual detail, but it gives the recipient a visible sign that the message genuinely came from you, and it sits on top of the authentication work you have already done.

You can check your own domain quickly: does your DNS hold an SPF record and a DMARC TXT record, and what policy level is DMARC set to? If you are stuck at p=none, or have no records at all, Wedevit can map your current email traffic and move SPF, DKIM and DMARC safely up to reject without breaking your legitimate senders, then set up a process to read the incoming reports on a regular basis.