How to Prevent Email Spoofing on Your Domain

A convincing fake invoice can arrive from an address that looks exactly like yours. Your customer sees your domain in the From field, replies to it, and may never realize the message came from somewhere else. That is why the effort to prevent email spoofing belongs alongside choosing a mail provider and setting up mailboxes.

Spoofing is not the same as someone breaking into an inbox. A criminal can forge the visible sender address without access to your account. The technical defenses are mostly DNS records: small pieces of configuration that tell receiving mail systems which servers may send mail for your domain and how to handle messages that fail verification.

They are manageable for a family domain, a freelancer, or a growing team. The key is setting them up carefully, then keeping them current as your sending tools change.

What email spoofing looks like

Email was built to move messages between systems that did not necessarily know or trust each other. The From address is easy to display, but it is not proof of who sent the message. A forged message might claim to come from `billing@yourdomain.com` while actually being sent from an unrelated server.

Attackers use this to request wire transfers, redirect payroll details, send fake password-reset notices, or impersonate a founder asking for a gift card. Personal domains can be copied too. A forged address may be used to pressure relatives for money or spread spam that damages the domain's reputation.

A customer may say, “I got an email from you,” even when you did not send it. Without authentication records, their mail provider has little reliable information to challenge that claim.

The three records that help prevent email spoofing

SPF, DKIM, and DMARC work together, but they do different jobs. Setting up only one is better than nothing. Setting up all three and enforcing DMARC gives your domain a much clearer defense.

SPF names permitted sending servers

SPF stands for Sender Policy Framework. It is a DNS record that lists the services allowed to send mail using your domain's envelope sender, also called the return path.

If you send only through one email provider, the SPF record can be simple. It becomes more complicated when you add a website contact form, accounting platform, help desk, ecommerce tool, or marketing service. Each service may need authorization.

SPF has a practical limit: receiving systems perform a limited number of DNS lookups. Piling separate records into DNS can also break SPF because a domain should publish one SPF record, not several competing ones. Consolidate authorized services into a single record and remove providers you no longer use.

SPF alone does not fully protect the address people see in their inbox. That is where DKIM and DMARC matter.

DKIM adds a signed message check

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing messages. Your provider signs each message with a private key. Receiving systems look up the matching public key in your DNS and check whether important parts of the message remained intact.

A valid DKIM signature says the message was authorized by a server holding that private key. It also helps preserve trust when mail is forwarded, which is one reason it is more durable than SPF alone.

Your email provider usually gives you the DKIM record to publish. Copy it exactly. A missing character, extra quote, or wrong host name can cause failures. After publishing, send a test message and use your provider's diagnostic tools or delivery information to confirm the signature passes.

DMARC tells recipients what to do

DMARC brings SPF and DKIM into focus. It checks whether one of them passes and aligns with the domain shown in the visible From address. Then it tells receiving mail systems what policy you request for failures.

The policy choices are straightforward:

• `p=none` asks for monitoring only. Messages are delivered normally, while reports show who is sending under your domain.
• `p=quarantine` asks recipients to treat failing messages as suspicious, often placing them in spam.
• `p=reject` asks recipients to refuse failing messages outright.
• The percentage setting lets you apply quarantine or reject to part of the mail stream while you test.

Start in monitoring mode if you have not mapped every legitimate sender. DMARC reports can look technical, but they reveal services you forgot were sending mail and unauthorized sources using your domain. Once legitimate mail consistently passes alignment, move gradually to quarantine and then reject. This staged approach avoids blocking a real receipt, automated notice, or support reply because a vendor was missed.

A reject policy is the strongest published instruction, but it is not an absolute guarantee. Receiving providers make their own delivery decisions. Still, it gives major mailbox providers a clear basis to reject many forged messages before they reach an inbox.

Build an inventory before changing DNS

The most common authentication mistake is not a bad record. It is forgetting a system that sends on your behalf.

Write down every source of outbound mail: your primary mail provider, website forms, store notifications, invoicing software, support systems, appointment tools, and any outside agency that sends as your domain. Include separate brands and domains if your organization uses them.

For each source, ask two questions: Does it need to use our visible From domain? Can it sign with DKIM that aligns with that domain? A service that cannot align may need a dedicated subdomain, such as `updates.example.com`, or a different sending setup.

This inventory also makes future changes less risky. When someone adds a new tool, authentication becomes part of the launch checklist rather than an emergency after messages start landing in spam.

A practical rollout plan

DNS changes can take time to appear across the internet, so avoid changing everything at once during a busy workday. A reasonable sequence is to publish DKIM for each authorized sending service, create one consolidated SPF record, then add DMARC in monitoring mode.

Give the reports time to accumulate. Review unfamiliar sending sources before assuming they are hostile. Sometimes they belong to a vendor, a legacy system, or a forwarding arrangement. Other times they are exactly what you hoped to find: unauthorized attempts to impersonate your domain.

After correcting legitimate failures, apply DMARC quarantine to a small percentage of mail. Increase it as you gain confidence, then consider reject. The right pace depends on how many tools you use. A solo consultant sending through one provider may move quickly. A business with several older systems may need a longer monitoring period.

FranklyMail includes guided MX, SPF, DKIM, and DMARC checks, which can make it easier to spot an incomplete setup when moving a domain or adding mail service.

Authentication does not replace account security

SPF, DKIM, and DMARC protect your domain from many forms of impersonation. They do not stop a criminal who has stolen a real mailbox password and is sending from an authorized account.

Use a unique password for every mailbox and turn on two-factor authentication. App passwords are useful when an older mail client cannot handle your normal sign-in flow, but treat them carefully: create only what you need and revoke them when a device or app is no longer in use.

Review forwarding rules and filters, especially after an account-security incident. Attackers often create hidden forwarding rules so they can keep receiving copies of mail after a password is changed. For teams, make payment-detail changes and urgent financial requests subject to an out-of-band confirmation, such as a phone call to a known number.

What to do when someone reports a spoofed email

Ask for the full message headers, not only a screenshot. Headers can show the sending path, authentication results, and return address. They help distinguish a forged message from a compromised account or a lookalike domain such as `yourdornain.com`, where an “rn” is made to resemble an “m.”

If the message is spoofed, check your DMARC policy and authentication results first. If your domain is still on monitoring mode, that report may be the reason the fake message was delivered. If the sender used a lookalike domain, your own DMARC record cannot control it, but you can warn affected contacts and report the abuse to the relevant provider.

If there is any sign a real mailbox sent the message, change its password, revoke unfamiliar app passwords and sessions where available, review rules, and check recent sent mail. Notify recipients promptly with a plain explanation of what happened and what they should disregard.

Email authentication is not a set-it-and-forget-it project. Review it when you change providers, launch a new website tool, retire a service, or add a sending domain. A few minutes of maintenance can keep your name from being used as someone else's disguise.