For Google Workspace, publish one valid SPF record that includes every legitimate sender, enable DKIM for the domain in Google Admin and DNS, then publish DMARC after SPF and DKIM are working. Verify real outbound messages and domain alignment before moving DMARC from monitoring toward quarantine or reject. Do not copy another company’s DNS values or create multiple SPF records for the same hostname.

SPF, DKIM and DMARC are related, but they do different jobs.

Do not add three DNS records from a tutorial and assume email is authenticated. Build the configuration from the services that actually send mail for your domain, then verify real messages.

Start with an inventory of senders

List every system that sends email using your domain.

That can include:

  • Google Workspace mailboxes;
  • website contact-form notifications;
  • CRM;
  • invoicing software;
  • newsletter platform;
  • help desk;
  • ecommerce system;
  • appointment platform;
  • transactional email service.

Do not publish the SPF record until you know which services need authorisation.

A third-party platform can fail authentication even when ordinary Gmail messages pass.

SPF: authorise legitimate sending sources

SPF is a DNS TXT record used to identify systems allowed to send for a domain in the SMTP envelope.

For a domain that sends only through Google Workspace, Google publishes the SPF value it expects. If other services also send mail, their requirements have to be incorporated correctly.

The important rule is one SPF record per hostname.

Do not create:

v=spf1 include:_spf.google.com ~all

and then a second separate SPF TXT record for a CRM. Multiple SPF records at the same hostname can cause SPF evaluation errors.

Combine authorised senders into the single policy according to provider guidance.

Remove systems you no longer use

An SPF record becomes a history of forgotten software if nobody maintains it.

When the business stops using a sender, remove it after confirming no legitimate mail still depends on it.

Google specifically recommends keeping SPF current when new third-party senders are added or old sources are retired.

Do not leave broad authorisation indefinitely “just in case”.

DKIM: sign mail with your domain

DKIM adds a cryptographic signature to outbound messages so a receiving server can verify that signed parts of the message were not changed and that the signing domain controls the published public key.

For Google Workspace, generate or obtain the DKIM record in the Google Admin console, publish the provided DNS value, then enable authentication in Admin after DNS is available.

Do not copy a selector or public key from another domain.

Your DKIM public key is domain-specific.

Verify DKIM on a real outbound message

After enabling DKIM, send a message from the actual business domain to an external mailbox you control.

Inspect the message authentication details.

Confirm:

  • DKIM result passes;
  • signing domain is the expected business domain;
  • SPF result is understood;
  • visible From address is correct.

Test more than one sending path if the business uses several systems.

A Google Workspace mailbox passing DKIM does not prove your invoice platform signs with the same domain.

DMARC: check alignment with the visible From address

DMARC builds on SPF and DKIM and evaluates whether an authenticated domain aligns with the domain the recipient sees in the From address.

This matters because a message can pass SPF for one domain while pretending to be from another.

Publish DMARC only after you understand the legitimate senders.

A common starting point is a monitoring policy so reports can reveal unknown or misconfigured sources before enforcement becomes stricter.

Do not jump to p=reject because a checklist says “stronger is better” if important systems have not been tested.

Use DMARC reports to find forgotten senders

Aggregate DMARC reporting can show services sending on behalf of the domain and whether SPF or DKIM alignment succeeds.

Review the reports for:

  • authorised Google Workspace traffic;
  • CRM or marketing platform;
  • website system;
  • invoice software;
  • unexpected senders;
  • authentication failures.

Classify each source before changing policy.

An unknown source may be an old legitimate service or spoofing. Investigate rather than assuming.

Separate marketing systems when appropriate

High-volume or third-party marketing systems can affect the main business domain’s sending reputation and authentication complexity.

Depending on the provider and strategy, a dedicated subdomain can create cleaner separation.

Example:

mail.example.co.za

Each sending subdomain needs the authentication configuration its sender requires.

Do not create a subdomain and then forget to publish SPF, DKIM and DMARC rules for it.

Website forms need their own test

A website form can submit successfully while its email notification fails.

Check how the form service sets:

  • From;
  • Return-Path;
  • DKIM signing domain;
  • Reply-To.

Do not configure the form to send “from” the visitor’s Gmail or corporate address if the sending platform is not authorised to send as that domain.

Use the provider-supported sender and set Reply-To to the customer where appropriate.

See the form-to-inbox test for the full chain.

Google sender guidelines make authentication operational

Google’s sender guidelines require authentication appropriate to sending volume and impose stronger requirements on higher-volume senders.

Even a small business should not wait until it becomes a bulk sender to set up its domain properly.

Authentication also helps protect the brand from simple spoofing and gives you better diagnostic data when delivery fails.

Test every sending service after DNS changes

After changing SPF, DKIM or DMARC, send controlled messages from:

  • Gmail/Google Workspace mailbox;
  • website form;
  • CRM;
  • invoice system;
  • marketing platform;
  • support system.

Record authentication results and inbox placement separately.

Passing SPF/DKIM/DMARC does not guarantee inbox placement. Reputation, content and recipient behaviour still matter.

Keep a DNS handover record

Document:

Item Value / owner
DNS provider
Domain owner
Google Workspace admin
SPF senders
DKIM selector
DMARC reporting address
Third-party mail systems
Last verified

Do not store admin passwords in this document.

The aim is to prevent the next web designer or IT provider from deleting a mail record they do not recognise.

Use the setup checklist in order

  1. Inventory senders.
  2. Check existing DNS.
  3. Create one correct SPF policy.
  4. Generate and publish Google Workspace DKIM.
  5. Enable DKIM signing.
  6. Verify real messages.
  7. Publish DMARC in an appropriate monitoring/enforcement stage.
  8. Review reports.
  9. Correct third-party alignment.
  10. Tighten policy only after legitimate mail is accounted for.

IDJoy can assist with domain, website and professional email setup through its current service options, with DNS changes documented rather than treated as copy-and-paste records.