How to stop others from sending email as your domain

Yes, someone can send email that looks like it came from your domain, and you cannot stop it by changing your web hosting or asking nicely. What you can do is publish three DNS records that together tell every receiving mail server how to check whether a message claiming to be from you is actually from you. That is the whole idea behind SPF, DKIM, and DMARC. None of them are products. They are TXT records you add to your DNS.

This post explains what each record actually does, why you need all three, what order to roll them out in, and what changes once you reach the strongest setting. By the end you should be able to look at a DMARC report and know what to do next.

Can someone else send email using my domain?

Yes. SMTP, the protocol that moves mail between servers, does not verify the From header. A sender can put anything there. That is why phishing campaigns impersonating banks, shipping companies, and small businesses keep working. The visible sender is just a label. Until you publish records that prove who you really are, no receiving server can tell your real messages from forgeries.

This is the problem SPF, DKIM, and DMARC were built for. They do not change how SMTP works. They publish a shared set of rules the receiving servers can check.

How does SPF actually work?

SPF (Sender Policy Framework) is a single TXT record at the root of your domain that lists the IPs and hostnames allowed to send mail for you. When a server receives a message claiming to be from you, it looks at the connection that delivered it and checks whether that sender is on your list.

SPF has a blind spot. It checks the connection-level sender (the envelope sender, sometimes called Return-Path), not the From header the user sees. If you allow mail from your web server but a phishing email arrives from a different IP with your domain in the visible From, SPF can still authenticate that message - it just authenticates against whatever domain the envelope sender used, which may be unrelated. SPF alone catches some forgery but leaves a wide hole.

SPF also breaks when mail is forwarded. Each forwarding hop introduces a new envelope sender. Once you exceed ten DNS lookups during SPF evaluation, you fail authentication under the SPF specification. That is a separate problem but worth knowing before you build a long SPF chain.

How does DKIM actually work?

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing messages. Your mail server holds a private key. The matching public key is published as a TXT record at a selector subdomain, something like selector1._domainkey.example.com. The receiving server fetches that record, checks the signature, and learns two things: that a holder of your private key signed the message, and that the body and a few key headers were not modified in transit.

DKIM has its own blind spot. It proves a message was signed by a key for a domain, but it does not require that domain to match the visible From. If a phishing campaign forges your From and signs the message with their own DKIM key on their own domain, DKIM authenticates - the message was signed - but DKIM is not aligned with your visible From, so DMARC will still flag it. More on that next.

DKIM survives forwarding better than SPF, because the signature stays with the message. With ARC (Authenticated Received Chain), intermediaries can sign that they saw and verified a message before forwarding it. ARC is increasingly supported by major receivers.

What does DMARC actually do that SPF and DKIM do not?

DMARC ties the visible From address to whatever passed SPF or DKIM. This is called alignment. It is also where DMARC announces what to do when a message fails.

A DMARC record is a TXT record at _dmarc.yourdomain.com. It contains:

• p: what to do with mail that fails alignment (none, quarantine, or reject)


• rua: where to send aggregate reports (mailto:dmarc-reports@yourdomain.com, for example)


• pct: what percentage of failing messages the policy applies to (so you can ramp up from 10 to 100)


• sp: subdomain policy (defaults to the same as p, but most operators leave this permissive while they get the main domain right)

Alignment is the part most people miss. SPF can pass for your domain, and the message can still fail DMARC, if the From header uses your domain but the envelope sender uses a different domain. Both SPF and DKIM have to be in alignment with the visible From for DMARC to consider the message authenticated.

Once you set p=reject, receivers that respect DMARC will refuse to deliver any message claiming to be from your domain that does not align with SPF or DKIM. That is what actually stops spoofing from reaching inboxes.

Why do I see SPF pass but DMARC fail?

This is the alignment problem above. SPF passed for the connection, but not for your domain. A common cause: a marketing platform or transactional sender that uses its own domain in the envelope sender but your domain in the From header. SPF authenticates against the envelope sender's domain, not yours, so it does not align, and DMARC fails.

The fix is to make that sender use a DKIM signature for your domain. Most ESPs (Mailchimp, SendGrid, Brevo, Postmark, and others) support a custom DKIM selector. Once they sign messages with your key, DKIM authenticates your domain directly, alignment is satisfied, and DMARC passes.

How do I roll out DMARC without breaking my own mail?

The safe rollout looks like this:

1. Publish an SPF record listing every system that sends mail for you (your own server, your transactional ESP, your marketing platform, your helpdesk, anything else).
2. Enable DKIM signing at every one of those senders using a selector per sender.
3. Publish a DMARC record with p=none and a rua address you actually read. This tells receivers to deliver everything but send you aggregate reports.
4. Read the reports. You will see every system that is legitimately sending for you and which of them pass or fail alignment.
5. Fix the legitimate senders that are not yet aligned. Usually this means turning on DKIM for them.
6. When 100 percent of your legitimate mail passes, move to p=quarantine with pct=10, watch for false positives, ramp to 100.
7. Move to p=reject at pct=10, ramp to 100. Once you hit pct=100 with p=reject, spoofing stops reaching inboxes.

A common mistake is moving to quarantine or reject before fixing alignment for every legitimate sender. The result looks like your own mail going to spam. The aggregate reports are how you prevent that. Skipping the reports is the single biggest reason DMARC rollouts fail. If reading raw XML reports sounds painful, this is where DMARC aggregate monitoring tools earn their keep: DMARCFlow, for one, turns those reports into a per-sender table that shows which legitimate senders are aligned, which are not, and what to authorize next.

A second common mistake is ignoring subdomains. By default DMARC applies to subdomains too. If your marketing platform sends from mail.yourdomain.com and you have not authorized it, those messages start failing when you go to reject. Either authorize them or set sp=subdomain-policy to keep the subdomain permissive while you fix it.

What changes when I move to p=reject?

Three things change, and they mostly help you. By this point your reporting is mature enough that the move from quarantine to reject is a formality you can monitor in the same DMARC dashboard that got you there.

• Spoofed messages stop reaching inboxes. This is the visible win. Phishing campaigns impersonating your domain will still be sent, but most major receivers will not deliver them.
• Your domain becomes eligible for BIMI. BIMI (Brand Indicators for Message Identification) lets you publish a logo that some mailbox providers display next to authenticated messages from your domain. BIMI requires DMARC at p=reject or p=quarantine.
• Aggregate reports still arrive. Even at p=reject you continue to receive RUA reports, so you can keep monitoring who is sending as you.

What does not change: DMARC does not stop lookalike domains. A phishing campaign from yourcompaany.com or your-company.com will still land in inboxes. Catching lookalikes is a different problem, covered by tools that watch certificate transparency logs and domain registrations rather than by SPF, DKIM, or DMARC.

Practical first steps

If you are starting from zero, this week:

• Inventory every system that sends mail as your domain. Include your primary mail, marketing platform, transactional sender, helpdesk, billing, and any other SaaS that emails on your behalf.
• Run a DNS lookup against your domain and check whether you already have an SPF record, a DKIM record, and a DMARC record at _dmarc.yourdomain.com.
• Publish the records you are missing. Start with a permissive DMARC (p=none) so you can see what is happening without breaking anything.
• Set a rua address and actually read the reports, even at low volume. A small domain produces a few reports per day. A busy domain may produce dozens. If you do not want to parse raw XML by hand, point the rua at a monitoring service (DMARCFlow parses these into a per-sender view) or any of the established DMARC monitoring providers - the point is to read the data, not to host it yourself.
• Once you reach p=reject at pct=100, you are not done. Domains go to other domains, senders change, ESPs update their signing. Keep reading the reports.

This is the part most teams skip, and it is the part that matters most for long-term spoofing protection. DMARCFlow ingests the aggregate reports and turns them into a per-sender view of which legitimate senders are aligned, which are not, and what to authorize next. Its free DNS Health check is a usable starting point before any paid plan; other monitoring providers cover similar ground. The point is to actually read the data before tightening policy rather than guessing.

FAQ

Can someone send email that looks like it is from my domain?

Yes. SMTP does not verify the From header. Anyone can put your domain there. SPF, DKIM, and DMARC together are what give receiving servers a way to tell real messages from forgeries.

What is the difference between SPF, DKIM, and DMARC?

SPF limits which IPs and hostnames can send for your domain. DKIM proves a message was signed by a key for your domain and was not modified in transit. DMARC requires that SPF or DKIM authenticate your visible From domain, and tells receivers what to do when neither does.

Why do I see SPF pass but DMARC fail?

Because SPF passes for the connection, not for your visible From. DMARC requires alignment between whatever passed SPF or DKIM and the From header the user sees. The fix is usually to enable DKIM signing for your domain at the sender that is misaligned. Your aggregate DMARC reports will show you which sender is causing the mismatch and how often, which is the moment a monitoring tool such as DMARCFlow saves you from chasing guesses.

How long does it take to roll out DMARC?

A small domain with one or two senders can reach p=reject in two to four weeks. A larger organization with many ESPs and SaaS senders usually takes three to six months because of the legitimate-sender cleanup work.

Do I need DMARC for subdomains too?

By default, yes. Subdomains inherit the parent policy unless you publish an sp override. Most operators set a permissive sp while they clean up the parent domain, then tighten the sp once everything is aligned.

Does DMARC stop phishing?

It stops exact-domain spoofing. Phishing from lookalike or cousin domains is a separate problem that needs lookalike monitoring, brand impersonation takedowns, and user awareness - none of which DMARC alone can fix.