Google Workspace Email Security

Three DNS records that together tell the rest of the internet which mail genuinely comes from your domain. SPF lists the servers allowed to send as you. DKIM cryptographically signs your outgoing mail so receivers can verify it was not forged or altered. DMARC tells receivers what to do when a message fails those checks, and asks them to report back on who is sending as your domain. Without them your mail is more likely to be filtered, and anyone can send messages that appear to come from your company.

Partly, and the gap is the important bit. SPF is straightforward and usually gets done during setup. DMARC is a record you publish yourself. DKIM is the one that catches people out: Google Workspace does not sign outgoing mail by default — the key has to be generated in the Admin console and the matching record published in your DNS as a deliberate step. Until that is done your mail is authenticated more weakly than it should be, and it is the single most commonly skipped item in a migration.

Frequently, yes, because authentication failure is the most common cause. Publish all three records correctly, confirm DKIM is actually signing, and check the DMARC reports for senders that are failing. What it will not fix is a genuine reputation problem from sending unwanted mail, or a specific recipient whose own filtering is unusually aggressive. Those need diagnosing from the message headers rather than guessing, which is a quick job for someone who reads them regularly.

The specification allows a receiving system ten DNS lookups while evaluating your SPF record, and every include: entry consumes at least one — often several, because the services behind them have includes of their own. Google plus an old provider still listed during migration plus a CRM plus an invoicing tool can exceed it easily. When it is exceeded the whole record becomes invalid rather than partially working, and nothing tells you: no bounce, no alert, just quietly degrading delivery. It is one of the first things we check when mail is going astray.

No, and doing so is the reliable way to stop your own invoices being delivered. Start at monitoring, where nothing is blocked and receivers simply report who is sending as you. Those reports will reveal legitimate senders nobody remembered — the booking engine, the accounts package, a courier integration. Stay there long enough to cover a full business cycle, including any monthly run. Then move to quarantine, which is reversible because failed mail lands in spam rather than vanishing. Only then reject. The whole sequence typically takes weeks rather than days, and the waiting is the point.

You get the reporting and none of the protection. A policy of monitoring tells receiving systems to take no action on messages that fail, so forged mail claiming to be from your domain is still delivered to your customers exactly as before. It is a very common place to stall, because monitoring feels like progress and enforcing feels risky. The honest framing is that until the policy says reject, the work is not finished.

It stops them forging your exact domain, which is the most convincing version of the attack. It does not stop a lookalike domain — one character different, or the same name with another extension — because the forger legitimately owns that domain and can authenticate it perfectly. Nor does it stop display-name spoofing from a free mail account. Those need your customers knowing to check, and a rule that payment detail changes are confirmed by a second channel rather than accepted by email.

It matters a great deal, and it is the thing most often missed. Any system that sends mail appearing to come from your domain — accounting software, CRM, marketing platform, booking engine, helpdesk — needs authorising, or it will fail authentication once DMARC is enforced. Finding all of them is exactly what the monitoring phase is for, and there is almost always one nobody remembered.

Yes, and the distinction is worth holding onto. Email authentication protects your domain from being impersonated to other people — it is outward-facing. General security controls protect your own accounts and data from unauthorised access: two-step verification, admin role separation, sharing rules, device policy. Both matter and neither substitutes for the other. A perfectly authenticated domain with an account somebody has compromised sends perfectly authenticated fraud.

Yes, and arguably more so. Volume affects how quickly a reputation problem develops; it does not affect whether your domain can be forged. A small business sending a handful of invoices a week is a more attractive target for payment diversion than a company sending thousands of newsletters, because the individual amounts are worth more and the correspondence is easier to imitate convincingly. Google and Yahoo have also tightened their requirements for bulk senders since 2024, which is pulling the baseline expectation upward for everyone.