Business email compromise rarely announces itself as a mail-system failure. The message arrives in a normal thread, refers to a real supplier, and asks finance to replace bank details before an invented deadline. Another message uses a lookalike domain that passes its own authentication checks, so the recipient sees no obvious technical warning. Email security therefore has two jobs: make unauthorised use of the organisation's real domains harder, and make high-risk business requests safe even when the message looks convincing. Mailbox filtering alone cannot do both.
SPF, DKIM, and DMARC solve related but different problems. SPF tells receivers which systems may send for an envelope domain. DKIM lets a receiver verify a cryptographic signature and the domain that signed it. DMARC checks whether the visible From domain aligns with a passing SPF or DKIM identity, then publishes a requested policy and reporting addresses. None of these controls verifies that a payment request is honest, and none blocks an attacker from authenticating mail on a newly registered lookalike. Those risks require domain monitoring, staff procedures, and independent confirmation for sensitive changes.
DomScan's Email Authentication check inspects published DMARC, SPF, DKIM, MTA-STS, and TLS-RPT configuration, including recursive SPF behaviour. The SPF and DMARC builders help draft records, but they do not know every service authorised to send for the organisation and they do not ingest aggregate DMARC reports. A clean check is therefore a configuration snapshot, not proof that all legitimate mail passes or that receivers will accept it. Use provider logs, DMARC aggregate data, and mailbox-provider diagnostics to confirm real traffic before moving a policy to enforcement.
Quick path: Run the Email Security Check against the sending domain, inventory every legitimate sender, then use the DMARC Builder and SPF Builder to draft changes for a controlled rollout.
Why business email security matters in practice
The visible From address carries authority far beyond the mail platform. Customers treat it as a support identity, employees use it to approve payments, and suppliers rely on it when account details change. A poorly governed marketing subdomain can damage delivery while a convincing lookalike can bypass the real domain's DMARC policy entirely. Compromised mailboxes add another route: the attacker sends from an authorised account inside an existing conversation. Good domain authentication reduces one large class of impersonation, but the business process must still assume that an authenticated message can be malicious.
Read technical signals in terms of the workflow they could affect. An MX record on a one-character lookalike means the domain can be configured to receive mail, but it does not prove abuse. A certificate for that name means issuance was logged, not that a phishing page is live. An unfamiliar source in aggregate DMARC data may be an attacker, a forwarding path, or a forgotten legitimate vendor. The response changes when that domain resembles the address used for payroll, invoices, password resets, or executive communication. Record both the observation and the business path it could imitate.
- Direct spoofing, lookalike domains, and trusted-conversation compromise are different attack patterns.
- The same domain evidence can be relevant to security, finance, support, and brand teams.
- Authentication is necessary but not sufficient for business email defence.
- Process controls work better when they are tied to the real domains your organisation uses.
How business email security works
Authentication starts with accurate sender inventory. Each customer-support platform, billing system, marketing service, ticketing tool, and corporate mail provider needs an approved domain and an accountable owner. Prefer DKIM signing with an aligned domain because it survives ordinary forwarding more reliably than SPF. Keep SPF below its DNS-lookup limit and avoid authorising broad provider ranges when a narrower mechanism is available. Publish DMARC first where reports can be reviewed, correct legitimate failures, and increase enforcement only after the team understands the traffic.
Authentication results and reputation are not interchangeable. A message can pass SPF, DKIM, and DMARC and still be unwanted, deceptive, or sent from a compromised account. It can also fail SPF after forwarding and pass DMARC through aligned DKIM. Receivers combine authentication with complaint rates, sending patterns, content, and their own policy. Track those receiver-specific signals through tools such as Google Postmaster Tools while keeping DNS configuration under change control. A single reputation score cannot stand in for the receiver's actual view of a sending stream.
Where teams usually get it wrong
A common mistake is publishing an SPF record assembled from guesses, then leaving `p=none` in DMARC indefinitely because nobody owns the reports. Another is authenticating the primary corporate domain while allowing campaign platforms to create unreviewed subdomains. Banners that label external mail can help, but users quickly stop noticing them and a compromised internal account will not trigger the warning. The deeper operational failure is separation: IT controls DNS, marketing adds senders, finance receives payment requests, and no one owns the full trust path.
Make sender onboarding a small production change. The request should name the service, sending domain, expected volume, DKIM selectors, SPF requirement, return-path behaviour, owner, and removal date if the use is temporary. Test authentication on real messages before launch. When a vendor is retired, remove its DNS authority instead of assuming an expired contract stops it from sending. This is mundane work, which is exactly why it needs a checklist rather than memory.
A more reliable operating model
Separate sending identities by purpose without creating more domains than the team can govern. Transactional, corporate, and marketing streams often benefit from distinct subdomains because a problem in one stream becomes easier to diagnose and contain. Keep the parent brand domains locked at the registrar, protect DNS changes with strong access controls, and assign a service owner to every sending identity. For payment details, payroll changes, credential resets, and supplier banking requests, require confirmation through a known phone number or authenticated business system rather than a reply to the message that requested the change.
A practical workflow
Begin with messages rather than DNS records. Collect samples from each legitimate sender and record the visible From domain, envelope sender, DKIM signing domain, provider, and business owner. Check whether SPF or DKIM passes and whether at least one passing identity aligns for DMARC. Fix sources that cannot authenticate, then remove obsolete authorisations. Publish reporting addresses that the team actually reviews. Document an enforcement plan by domain, including rollback conditions, because a rushed reject policy can block password resets and invoices just as effectively as an attack.
Review aggregate DMARC data for unexpected sources, alignment failures, and changes in legitimate volume. Watch DNS for deleted or modified SPF includes, DKIM selectors, and DMARC policy. Check mailbox-provider diagnostics for complaint and delivery changes. Separately monitor high-risk lookalike variants for registration and active mail or web signals. Each signal has a different owner: messaging engineers fix authentication, the service owner confirms a sender, finance validates a payment workflow, and security investigates impersonation. Routing everything to one generic queue usually means nobody closes it.
Prioritise identities by the harm a convincing message could cause. Domains used for account recovery, billing, legal notices, executive mail, and customer support deserve immediate review when authentication or DNS changes. A low-volume event invitation may tolerate slower triage, but it still needs an owner and removal plan. Lookalikes that can plausibly imitate a payment or login flow should outrank merely similar names with no active DNS. Severity should follow the trusted workflow, not the number of characters that differ.
What good monitoring looks like
Good alerts include the affected domain, record or sender, prior state, current state, collection time, and owner. An alert that says DMARC failed is incomplete unless it shows which identity failed alignment and whether the source is approved. A lookalike alert should separate registration from activation signals and avoid calling the registrant malicious without evidence. For an actual suspicious message, preserve the full headers, message body, links, attachments, and the business action requested. That package lets responders investigate the mail path while finance or support stops the associated transaction.
Trends matter, but only when the underlying measurements are comparable. A sudden rise in SPF failure may follow a forwarding change while aligned DKIM keeps DMARC healthy. A complaint spike may affect one marketing stream rather than the corporate domain. A newly registered lookalike may remain parked for months before mail records appear. Keep the raw observations and note provider or policy migrations beside the chart. Otherwise the team may treat a reporting change as an attack, or miss a slow loss of control because the overall percentage still looks acceptable.
Where DomScan helps
DomScan can check the public configuration around an email domain and help investigate nearby names. Email Authentication reports DMARC, SPF, DKIM, MTA-STS, TLS-RPT, and recursive SPF findings. Domain Reputation adds a scored snapshot of DNS, TLS, blacklist, parking, web, and email signals with confidence metadata. Typosquatting and Brand Protection tools help rank lookalike candidates. None of these views reads message content, confirms a supplier's bank account, or replaces DMARC aggregate reporting and receiver diagnostics. Use them as domain evidence inside a broader mail and business-control programme.
Independent references: Review Google Email Sender Guidelines and RFC 7489 for baseline details and neutral operational guidance.
The safest response to a believable payment-change email is still an independent check through a contact path the requester did not supply. Domain authentication makes forged use of the real brand harder and gives receivers a policy signal, but it cannot make human intent machine-verifiable. Keep the DNS controls accurate, review how legitimate mail behaves, and design sensitive workflows so one convincing message cannot move money or credentials on its own. That combination is less dramatic than a new filter, and much harder for an attacker to route around.