GOSS Interactive SPF, DKIM and DMARC setup, step by step

Quick answer: For the GOSS-hosted Digital Platform using Amazon SES, ask GOSS to verify your approved sender domain. GOSS supplies the SPF and DKIM DNS records; publish the complete issued records, retain them, obtain verification confirmation and test the intended live sending path. There is no universal GOSS selector, public key or account-specific target to copy from this article.

This guide covers the GOSS-managed SES route, not self-hosted iCM, your own SMTP relay or unrelated Amazon SES accounts. No customer account, DNS changes or delivered-message tests were performed.

Establish the route and resolve the policy prerequisite

GOSS's email-security documentation describes two distinct options: hosted sites using Amazon SES, and applications relaying through the customer's own mail server. Confirm the actual environment and route with your GOSS contact before editing DNS. Do not configure an unrelated AWS console or switch to a corporate relay to follow this guide.

The same current GOSS page states that primary-domain senders need a relaxed DMARC policy and that strict policy rejects their messages. Treat this as a provider-specific prerequisite that must be reconciled before deployment, not a universal rule of DMARC or permission to weaken your policy. Ask GOSS for the intended visible From, DKIM signing domain (d=), SMTP MAIL FROM domain and supported alignment behavior for your exact route.

Under current DMARC rules, adkim controls DKIM alignment and aspf controls SPF alignment. Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. These alignment settings are separate from p and sp, which specify requested DMARC enforcement for the policy domain and subdomains. GOSS’s wording “relaxed/strict DMARC policy” does not establish whether it means alignment settings or enforcement settings. Ask GOSS to resolve both meanings for your deployment before proceeding. Strict DKIM alignment can pass when the intended signature passes and its signing domain exactly matches the visible From. A child envelope domain does not automatically satisfy strict SPF alignment. Do not silently change adkim, aspf, p or an inherited policy to work around a source-document assertion. If GOSS cannot support your approved identities and current policy, stop for a supported design decision.

Request the correct domain-verification packet

The sender-verification instructions say to tell GOSS which domain you want to use. GOSS then provides the DNS records for SPF and DKIM. This is a managed provisioning process, not a documented self-service Generate button.

Agree the scope before requesting records:

• Exact site, production environment and managed SES route.
• Approved sender domain and addresses used by each relevant application flow.
• Existing SPF and direct or inherited DMARC policy.
• Authoritative DNS zone, including any delegated child or _domainkey namespace.
• Existing selectors, custom envelope domains and shared dependencies that must remain.

GOSS recommends a separate website subdomain. Its example explains that verifying website.my-company.com permits addresses in that domain. This is a choice of sending identity, not a recommendation to impersonate the corporate apex or create a less-protected exception. Obtain approval for the actual visible From domain and its user-facing implications.

Request a complete public packet: record type, full owner, full value/target and purpose for each entry; applicable SMTP envelope owner; and how GOSS will confirm verification and signing. Record which records authorize SPF, which support DKIM and whether any additional mail-routing records are required. Private keys stay with the signing service. Never paste private keys into DNS, support screenshots or public documentation.

Publish only the issued SPF changes

SPF evaluates SMTP MAIL FROM, or HELO for relevant empty-envelope messages, not automatically visible From. Have GOSS identify the evaluated domain. Adding an include to an unrelated apex cannot fix a provider-owned envelope identity.

The GOSS security page instructs customers to add Amazon server details to existing SPF; use the exact applicable instructions in the issued packet rather than guessing a universal include, IP list or region. At the evaluated owner:

1. Inspect all TXT records and identify the existing v=spf1 policy.
2. Preserve legitimate sending services and qualifiers. Add approved authorization to the single existing policy, not a second SPF record.
3. If multiple SPF policies exist, repair the duplication with the administrator before proceeding.
4. If no policy exists, inventory all authorized sending routes before creating one.
5. Place applicable mechanisms before final all. Do not change an existing ending merely to match a sample. redirect is ignored when an all mechanism exists.
6. Evaluate the ten DNS-dependent term budget, including nested mechanisms and modifiers that count. This is not simply a limit of ten visible includes. Do not replace managed provider ranges with a guessed static IP list.

Preserve the separate records for corporate mail. For example, the Microsoft 365 authentication guide concerns that distinct route, not a substitute for GOSS-managed SES.

Publish the complete DKIM records at authoritative owners

GOSS states that AWS generates and retains the private key, and that DNS publication is part of domain verification. Use the actual issued public record set, retaining exact types and complete values. Do not infer TXT versus CNAME, a selector count or a key from another customer's screenshot. If the packet is incomplete or ambiguous, resolve it with GOSS before publishing.

Illustrative owner mapping, not issued values:

Replace selector and every example domain with the approved packet. Check the resulting full owner so your DNS interface does not append the zone twice. Existing NS delegation determines where the record belongs; do not remove it to force a parent-zone entry to work.

For TXT, preserve the entire issued tagged public value. For an issued CNAME, preserve its full target and ensure no conflicting TXT, A, AAAA, MX or second CNAME exists at that owner. Use DNS-only behavior, not HTTP proxying. If the provider requires literal CNAME answers, ensure they remain visible: disable a relevant per-record flatten control where available, and check whether zone-wide, apex or same-zone behavior suppresses the alias. Use your DNS host's supported controls for this record; do not disable settings globally. If mandatory flattening cannot preserve the required answer, stop and coordinate a supported configuration.

Do not change MX, parent nameservers, DNSSEC, credentials or forwarding destinations merely because another SES tutorial contains them. If GOSS issues additional routing records, compare every exact owner, priority, target and destination with the authorized routing plan before implementation. Copying a packet is not approval of its consequences.

Confirm verification and signing separately

The official GOSS verification page says completion can take a few hours after DNS changes. It also says records are checked again periodically and must remain in place. Do not delete a verification or DKIM record after the first success.

1. Query authoritative DNS and an independent resolver for every issued owner. Confirm exact type and value, a single valid SPF policy and any required literal aliases.
2. Allow relevant TTL caches to expire. Obtain GOSS confirmation that the intended domain in the intended environment is verified. Do not invent a green dashboard badge or assume customer AWS-console access.
3. GOSS states that SES starts signing mail matching a verified sender domain. Confirm that your actual production flows use that intended sender and route, rather than treating DNS presence as proof of application behavior.
4. Send an approved, non-sensitive test to a controlled valid recipient through the intended production path. Do not broadcast to real users or submit a consequential workflow merely to make a test email.

GOSS's non-production email documentation, says its development/test environments use isolated MailDev capture services. MailDev does not forward captured mail. Seeing a message there tests application output, not public SES delivery, DKIM or DMARC. Do not redirect a test environment to public SMTP as a shortcut. Coordinate a safe production-path test with the administrator when necessary.

Acceptance: prove the intended signature and alignment

Use receiving results created inside the actual recipient service's known processing boundary, following its documented handling of externally supplied Authentication-Results. A familiar authserv-id or header position alone is not trust; ignore attacker-supplied result fields.

Record visible From, actual SMTP MAIL FROM, the intended DKIM d= and selector s=, and trusted results. Accept the new branded DKIM route only when:

• The intended GOSS/SES signature passes.
• Its signing identity aligns with the approved visible From under effective adkim.
• The trusted receiver records dmarc=pass.

A generic DMARC pass through SPF does not prove DKIM. A provider-rewritten visible From is not success for your approved brand identity. Assess SPF and aspf separately and repeat tests for materially different flows. Authentication does not guarantee inbox placement.

Troubleshoot and retain a safe rollback

Repair SPF faults even if aligned DKIM allows DMARC to pass. Retain the original DNS values, approved packet, GOSS verification confirmation and minimal header evidence. Roll back only an erroneous approved change, preserving subsequent shared changes and keys needed by queued messages. Keep GOSS-required verification records while the service remains authorized.

Preserve DMARC and reporting

This guide verifies compatibility with your existing policy; it does not create a new DMARC policy. Preserve direct and inherited protection and authorized report destinations. Establish a separate approved plan if no applicable policy exists rather than copying a monitoring record into a protected child domain.

If reporting destinations are reviewed separately, compare the destination's Organizational Domain with the policy domain's Organizational Domain. When different, the report-generating receiver must check DNS authorization before sending; when the same, that external-destination check is excepted. RFC 9990 section 4 defines the rule. DNS authorization is not the owner's permission to disclose report data.

Common questions

Can I remove the DNS records after GOSS verifies them?

No. The official instructions require retention because verification is repeated; removing them can disrupt the service.

Does every GOSS installation use the same SPF and DKIM records?

No universal packet is established by the public instructions. This guide covers GOSS-managed SES. A customer SMTP relay is a different route with its own authentication and availability requirements.

Must I weaken strict DMARC to use GOSS?

Do not weaken it automatically. GOSS's current documentation asserts a relaxed-policy prerequisite for primary-domain senders. Reconcile that with your approved exact signing/envelope identities and effective policy with GOSS before deployment; the general DMARC protocol can support strict alignment when the identities match exactly.