Email looks like a simple system: you press send and a message arrives. Underneath it is a pile of standards written over four decades, and nobody designed the whole thing at once. Authentication was bolted on afterwards, which is why so much advice about it sounds plausible and turns out to be wrong in practice.
These six claims come up again and again when a business finds that its invoices go to spam, or that someone has been sending messages in its name. Each gets a verdict, then the reasoning and a way to check it. The common thread is that email trust is earned by records you publish and behaviour you show over time, and not granted because you own a domain.
1. Email sent from my own domain is automatically trusted
Myth
Receivers have no reason to trust a message just because it carries your domain in the From line, since anyone can forge that. Trust is built from SPF, DKIM and DMARC alignment, the reputation of the sending IP address, and recipients' behaviour over time.
Plenty of small senders discover this only when the first batch of invoices lands in spam. Set up authentication before you need it.
The From header is just text typed by whoever composes the message. The original mail protocol never checked it, so a receiving server looking at a message that claims to be from [email protected] has to decide for itself whether to believe it. Over the years, receivers have settled on four independent tests, and each one answers a different question.
- SPF asks whether the connecting server's IP address is on the list that the domain says may send for it.
- DKIM asks whether the message carries a cryptographic signature that matches a public key in the domain's DNS, and whether the content was altered after signing.
- DMARC asks whether the domain in the visible From line lines up with the domain that passed SPF or DKIM, and tells the receiver what to do if it does not.
- Reputation asks what the sending IP address and domain have done recently: how many people complained, how many addresses bounced, whether the volume suddenly jumped.
A brand-new domain sending its first thousand messages from a new address is in the worst position, because it has no history at all. Large mailbox providers are cautious with unknown senders and increasingly strict about authentication, and since 2024 the biggest of them have required bulk senders to authenticate properly. That is why a small shop can send ordinary email for months without trouble, then see a spike in spam placement the week it starts a mailing.
The fix is dull but effective: publish SPF, enable DKIM signing in your mail system, add a DMARC record, and send at modest volume at first so reputation builds. The SPF builder and DMARC builder produce the records. To see how a real message fared, open it in your mailbox, choose "show original" and look for spf=pass, dkim=pass and dmarc=pass in the Authentication-Results header.
2. Email from my domain is protected from spoofing by default
Myth
The mail system lets anyone put any address in the From line. Protection comes only from the authentication records you publish and the policy you set. Without a DMARC policy that rejects failures, many receivers will deliver forged mail.
If your domain handles invoices or payments, this is worth fixing sooner rather than later.
It is easy to demonstrate the problem, and just as easy to make it worse by trying. Anyone with a basic mail script can send a message with your address as the From line, from their own server, with no access to your account at all. Whether it reaches an inbox depends on what your domain publishes. If there is no DMARC record, a receiver sees a forged message with no instruction on what to do about it, and each provider applies its own judgement. Some will catch it through other signals. Many will not.
A DMARC record changes that by stating a policy. There are three: none (report only, take no action), quarantine (treat failures as suspicious, usually the spam folder) and reject (refuse them). Only the last gives strong protection against forgery of your exact domain. A typical starting record looks like this:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"The pattern attackers use most with businesses is not exotic. They send a message that appears to come from the finance director to the accounts clerk, asking for a payment to a new bank account. With no enforcement, nothing in the technology stops it. Alongside enforcement, a firm should have a human rule that bank detail changes are confirmed by phone.
Two limits are worth knowing so you do not overestimate DMARC. First, it protects your exact domain in the From line. It does not stop someone registering examp1e.com or example-invoices.com and sending from there. Second, forwarding and mailing lists can break SPF and sometimes DKIM, which is one reason to roll out enforcement gradually, as claim 4 explains.
v=spf1 -all) and a DMARC record with p=reject, so that forged messages are refused.3. The more SPF includes the better
Myth
Each include adds DNS lookups, and the standard allows ten. An overloaded SPF record fails validation entirely, and some receivers treat that as a fail.
List only the services that actually send as you, and remove old ones when you stop using them.
SPF is a single TXT record that lists who may send for the domain. The include: mechanism says "also accept whatever this other domain's SPF record accepts", which is how you authorise a newsletter service or a ticketing system without knowing its IP addresses. The catch is that every include makes the receiving server do a fresh DNS lookup, and those can nest: your include may itself include another. The specification caps the total at ten lookups that trigger further DNS queries. Go past ten and the result is a permerror, which a receiver may treat the same as a fail.
This catches people out because each new tool brings its own instruction: add this include to your SPF. The CRM, the helpdesk, the booking system, the survey tool, the old newsletter service you stopped using in 2021. Each addition looks harmless, and the record is fine until the day it crosses the line and mail starts failing for no visible reason. The failure appears for all senders at once, including your main mail server, which makes it confusing to diagnose.
Ways to keep the record in shape:
- Make a list of everything that actually sends email as your domain. Ask around; marketing and finance often use services IT has never heard of.
- Remove includes for services you no longer use. Check the sending logs if unsure.
- Where a service sends from a fixed IP you control, use
ip4:203.0.113.25orip6:2001:db8::25, which cost no lookups. - Move bulk or marketing senders to a subdomain such as
news.example.com, which gets its own SPF record and its own ten lookups, with its own reputation as a bonus.
Be wary of so-called SPF flattening, where the includes are replaced by lists of IP addresses. It works, but providers change their addresses, and a flattened record that nobody refreshes goes stale. Only use it with automation behind it.
4. A DMARC policy of reject is best from day one
Myth
Rejecting is the end goal, not the starting point. If you turn it on before every legitimate sender is authenticated, you will block your own newsletters, invoices or system emails.
Start with monitoring, read the reports for a few weeks, fix the sources that fail, and then step up through quarantine to reject.
The reasoning rests on one fact: most organisations do not know everything that sends mail on their behalf. The mail server is obvious. The website contact form, the accounting package, the scheduling tool, the old server in the cupboard and the marketing platform are less so. With p=none and an rua address, receivers send you daily aggregate reports listing every source they saw using your domain, with pass and fail counts. They are XML files, tedious to read raw, so most people feed them to a free report viewer or a service that summarises them.
When failures are down to junk and forgeries, you move to p=quarantine. The optional pct tag lets you apply the policy to a percentage of failing mail, so you can begin at 10 and work upwards while you watch for complaints. Only once a few weeks pass without a legitimate sender failing do you switch to p=reject.
What goes wrong with an immediate reject is concrete. A customer's invoice is sent by the accounting package, which sends from its own servers and has never been given a DKIM key for your domain. The very first message fails DMARC and is bounced or discarded. Nobody tells you, since the customer never receives it, and the first sign is a payment that does not arrive. Forwarded messages are another source of surprise, because forwarding commonly breaks SPF; DKIM survives it, which is one more reason to turn DKIM on everywhere.
Keep the reports coming even after reject. New tools get adopted, and the reports are how you notice before your customers do.
5. Newsletters are fine to send from the web server
Myth
A hosting server's mail function is built for occasional messages. Large mailings can trip hourly limits, damage the IP's reputation for all customers on the server, and end up in spam.
A mailing service handles authentication, unsubscribe handling, bounces and reputation, and costs little for small lists.
On shared hosting, your site's PHP code usually sends mail through the server's local mail system, from an IP address that hundreds of other accounts also use. That works for order confirmations, password resets and the contact form. It is a poor fit for sending a few thousand messages in a burst, for several reasons.
Hosts set hourly limits per account, often in the low hundreds of messages, specifically to protect the shared IP, so a larger send is cut off part way and the rest sits in a queue or is rejected. Even where limits are generous, a mass mailing generates bounces and complaints, and those count against an address that other customers depend on. A single bad campaign can land the IP on a blocklist, and then everyone's mail on that server starts to suffer, including yours. The newsletter was never built to handle bounce processing, so dead addresses stay on your list and the damage compounds.
A proper mailing service gives you things a web server cannot: DKIM signing for your domain, bounce handling that removes dead addresses, one-click unsubscribe (which major providers now expect for bulk senders), complaint feedback, and sending IPs managed with deliverability in mind. For a list of a few hundred or a few thousand people, the cost is small or nothing. The law matters here as well: in many places, you need consent and a working unsubscribe for marketing mail, and a mailing service builds that in.
The rule of thumb we give: transactional messages (one person, triggered by an action) can go through your hosting mail, ideally via authenticated SMTP rather than the PHP mail function. Anything that goes to a list belongs elsewhere.
6. If the email reaches my inbox, it reaches everyone's
Myth
Different providers use different signals. A message accepted by one may be filtered by another, and the same message can land in the inbox of one person and in the junk folder of someone else, depending on their history.
Test with several providers and watch for complaints.
Your own inbox is the worst test environment you have. You know the sender, you have replied to them before, and your mailbox has learned from your behaviour: it trusts senders you open and interact with. A recipient who has never heard of you, and has a different provider with different filters, is in a different situation altogether.
Filtering is personalised. Large providers weigh sender reputation, authentication results, the content of the message, whether links point to domains with a poor record, and, importantly, what this specific recipient has done with mail like it. If a person marks one of your messages as spam, that affects their future placement and a little of everyone else's. If they open, reply and move your messages to the inbox, the opposite happens.
Some other things that make results differ between recipients:
- Corporate mail gateways often apply their own rules, such as blocking messages with certain attachment types, on top of the provider's.
- Providers disagree about new domains. One will deliver normally and another will hold the first messages for scrutiny.
- Tracking pixels, image-heavy layouts, URL shorteners and all-caps subject lines all push in the wrong direction on some systems and are ignored by others.
- Two messages with the same text but different sending IPs can be treated differently.
To test properly, set up a few seed mailboxes at the major providers and at one business-hosted domain, send your actual message, and check where it lands, including the spam folder. Look at the Authentication-Results header in each. Free test addresses from mail-testing services will give a score and list the authentication results too. After a larger send, watch bounce rates and any complaint reports your mailing service gives you; a complaint rate that creeps up is the early warning.
The best protection is dull consistency: authenticated mail, a clean list of people who asked for it, a steady sending pattern, and a visible way to leave. Reputation takes weeks to build and days to lose.
A ten-minute check
You can see most of what receivers see with a few commands and one test message.
dig example.com TXT +short
# look for the line starting v=spf1
dig _dmarc.example.com TXT +short
# your DMARC policy, if any
dig selector1._domainkey.example.com TXT +short
# a DKIM key; the selector name depends on your mail systemThen send a message to a mailbox you control at another provider and view the original headers. Look for spf=pass, dkim=pass and dmarc=pass and check that the domain shown beside each matches the From address. If any line says fail, softfail or none, that is where to start. The troubleshooting guide has a checklist for mail that is bounced or going missing, and the glossary explains terms such as alignment and selector.