AFAS Online SPF, DKIM and DMARC setup, step by step

For Profit email sent through the AFAS Online mail server, publish AFAS’s two DKIM CNAME records, request DKIM in the AFAS customer portal, then enter the issued credentials in each relevant Profit environment. DKIM is mandatory from Profit 8. AFAS strongly recommends retaining or adding include:spf.afas.online in your existing SPF policy. Finish by checking a delivered message for your intended domain’s DKIM signature and DMARC alignment. Current AFAS Online setup guide, in Dutch

This guide covers AFAS Software’s built-in AFAS Online sending route in Profit. An external SMTP server, Exchange Online or Gmail connection is a different route with different authentication ownership. No customer account, DNS configuration or live delivery was tested.

Identify the Profit environment and actual sender

Open Algemeen / Omgeving / Beheer / Eigenschappen > E-mail (General / Environment / Management / Properties > Email). Check the configured mail-server type before changing DNS. The AFAS CNAMEs below apply to AFAS Online, not every message generated by Profit. AFAS separately documents external mail-server configurations.

Record the environment, subscription, message type and complete visible From address. Invoices, payroll messages and automatic notifications may use different sender settings. Check the environment, administration, employer and message-template settings that apply to the workflow. A template can override the administration’s sender; automatic notifications can use the environment’s automatic sender unless a template supplies another address. AFAS sender selection

Create a small inventory before implementation:

A parent domain’s DKIM approval does not establish that a different From domain has been approved. Use a domain your organization controls and identify every additional domain before changing payroll or invoice delivery.

Follow the current DKIM requirement, not the older English procedure

AFAS’s current Dutch setup guide and DKIM checklist state that DKIM is mandatory from Profit 8. The older English page still describes DKIM as an additional option and SPF as a prerequisite. For current Profit 8 behavior, use the Dutch procedure: DKIM is required, SPF is strongly recommended, and the request can be completed without SPF when DKIM is used. If you retain or add SPF, configure it correctly before submitting the request. Current setup and DKIM checklist

This does not justify deleting a domain’s SPF policy. That policy may authorize employee email and other legitimate applications. It also does not make SPF errors harmless. Check SPF independently even if DKIM provides the aligned pass that DMARC needs.

DKIM signs message content and selected headers; it does not encrypt the message or prevent someone from reading it. DKIM specification

Publish both AFAS DKIM CNAME records

For a sender such as accounts@example.com, the official records are:

Replace example.com with the exact domain being requested. The two AFAS targets are documented shared service targets, not invented tenant identifiers. The request credentials, however, are issued by AFAS and must not be copied from another customer. Official record values

Notice the underscore: your record owner contains _domainkey; the AFAS target contains domainkey without that underscore. Do not “correct” the target to match the owner.

Publish at the authoritative DNS provider, which may differ from the registrar or website host. Where the editor automatically appends your domain, the host fields are afasonline1._domainkey and afasonline2._domainkey. Where it requires complete names, enter the full owners. Follow its trailing-dot convention for targets. AFAS specifically warns that entering a complete owner in an editor that appends the domain can produce a doubled name. AFAS CNAME troubleshooting

If AFAS has approved the child sending domain, map both issued selector owners for that domain rather than assuming the apex records cover it. For an issued signing domain such as news.example.com, the illustrative full owner is afasonline1._domainkey.news.example.com. In an editor relative to the parent example.com zone use afasonline1._domainkey.news; in a separately delegated news.example.com zone use afasonline1._domainkey; in a delegated _domainkey.news.example.com zone use only afasonline1. Repeat the mapping for afasonline2; keep both corresponding AFAS targets unchanged. The example child name is a placeholder, not a newly authorized AFAS domain. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Before saving:

• Inspect both owners for existing records and determine who uses them. Do not overwrite an active delegation to another service.
• Keep these records DNS-only if your host offers a web proxy. Leave authentication CNAMEs unflattened so their aliases remain publicly visible. On Cloudflare, both record-level flattening and a zone-wide “flatten all CNAMEs” setting can interfere even when the record is DNS-only. Review any wider effect before changing a zone-wide setting. Cloudflare’s CNAME verification guidance
• Do not publish a TXT public key alongside a CNAME at the same owner. Ordinary data cannot coexist with a CNAME there.
• Preserve mailbox MX records, website records and unrelated DKIM selectors.
• Save a record export and the previous TTLs so an authorized administrator can reverse only the affected changes.

The CNAME ownership restriction comes from DNS alias rules. If GoDaddy hosts the authoritative zone, use the GoDaddy DNS publishing guide for the editor workflow; it does not replace AFAS’s record values.

For the two AFAS aliases, turn the relevant per-record Flatten option off where supported and ensure applicable whole-zone settings do not suppress the literal CNAME answers. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the setting; these are DNS-host behaviors, not AFAS controls. If mandatory behavior or a shared setting prevents the issued answer, stop and coordinate a supported configuration without breaking dependent services or removing an existing NS delegation. Cloudflare flattening controls and limits.

Request DKIM and activate it in Profit

DNS publication and Profit configuration are two required stages, not alternative ways to enable signing.

1. Confirm both CNAMEs resolve correctly.
2. Sign in to the AFAS customer portal as an administrator.
3. Open Mijn gegevens / Abonnementen / Mijn abonnement and select the subscription associated with the Profit environment.
4. Choose DKIM-aanvraag aanmaken and enter the intended From domain, without the mailbox name or @.
5. Submit the request. Track it through Mijn gegevens / Organisatiegegevens / Mijn klantdossier.
6. After approval, retrieve the issued username and password using the response in the request. AFAS says the password link is valid for 30 days. Store the credentials securely, not in DNS or a shared troubleshooting screenshot.

If records were absent when the request was submitted, correct DNS and choose Opnieuw insturen to resubmit. A DNS repair alone does not resubmit a rejected request. AFAS request procedure and rejection handling

In the relevant Profit environment:

1. Open Algemeen / Omgeving / Beheer / Eigenschappen > E-mail.
2. Select AFAS Online as the mail-server type.
3. Enter the username and password from the approved DKIM request. The DKIM toepassen bij uitgaande e-mails setting is always selected for this route from Profit 8 and cannot be cleared.
4. Set the intended automatic email sender, then check lower-level sender overrides.
5. Save and close. AFAS documents an environment restart, so arrange a time when no users are logged in.

Do this for every environment that needs the configuration. AFAS allows the same domain’s issued credentials to be used in multiple environments. An additional sending domain needs its own CNAMEs and separate request; after AFAS adds it to the existing configuration, new credentials need not be entered again. Environment activation and additional domains

Add AFAS to SPF without replacing existing senders

The current AFAS authorization term is:

include:spf.afas.online

When adding it to an existing SPF policy, preserve the other authorized senders and place the term before the terminal all mechanism. Do not create a second v=spf1 TXT record at the same owner. Do not change the final qualifier merely to match an example. AFAS identifies _spf.afasonline.nl as an obsolete authorization; review and replace that legacy AFAS term with the current one without deleting unrelated authorizations. Current SPF and legacy-record guidance

For illustration only, if a domain genuinely sends through Microsoft 365 and AFAS Online, a merged policy could look like:

v=spf1 include:spf.protection.outlook.com include:spf.afas.online -all

This is not a universal replacement record. An existing policy may contain other senders, a different terminal qualifier or an intentional redirect= arrangement. Review that complete design before editing. The official AFAS page’s illustrative IPv4 address is not a value to copy into production.

SPF checks the connecting server against the SMTP MAIL FROM domain, normally reflected in Return-Path. The receiver records this identity as smtp.mailfrom. For a null reverse-path, SPF uses HELO. It does not authenticate the visible From address directly. AFAS’s public workflow does not establish one universal envelope domain for every message, so capture it from a real sample. SPF identities

If SPF authenticates an AFAS-owned envelope domain, adding an include at your own domain does not turn that envelope into your domain. SPF pass and SPF alignment are separate findings.

The SPF limit is ten lookup-causing terms across the evaluated chain, including nested includes and redirects. It is not simply ten visible include strings. Avoid manually flattening AFAS’s current IP addresses into a permanent list: service changes can make the copy stale. Resolve duplicate policies, obsolete terms and unnecessary lookups with the domain’s mail administrator. SPF processing limits

Keep DMARC under the domain owner’s control

AFAS does not activate DMARC for your domain. Inspect the current record at _dmarc for the visible From domain and its applicable parent policy. Preserve existing enforcement, reporting destinations and alignment settings. Never add a second policy or weaken p=reject to make a single application easier to configure. AFAS DMARC responsibility

For a new monitored deployment with no existing applicable policy to preserve, an illustrative record at _dmarc.example.com is:

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use only an approved, functioning report destination. p=none requests monitoring rather than enforcement; it does not override recipient filtering. Review all legitimate senders before increasing enforcement. Avoid enabling failure reports without a privacy and retention decision. DMARC policy and aggregate-report destination validation

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

DMARC passes when at least one mechanism both authenticates and aligns: SPF or DKIM. Relaxed alignment allows a shared organizational domain. Strict aspf=s or adkim=s requires an exact domain match for that mechanism. For example, bounce.example.com can align with example.com under relaxed SPF but not strict SPF. The DKIM comparison uses the signature’s d= domain, not its selector or CNAME target. Identifier alignment

Validate DNS and the actual AFAS message

Check authoritative and recursive DNS

Substitute your domain and one of its authoritative nameservers. These are diagnostic commands, not results from a tested customer domain.

dig +short NS example.com
dig @ns1.example.net CNAME afasonline1._domainkey.example.com +noall +answer
dig @ns1.example.net CNAME afasonline2._domainkey.example.com +noall +answer
dig +short CNAME afasonline1._domainkey.example.com
dig +short CNAME afasonline2._domainkey.example.com
dig +short TXT afasonline1.domainkey.afas.online
dig +short TXT afasonline2.domainkey.afas.online
dig +short TXT example.com
dig +short TXT _dmarc.example.com

Both selector owners should return the exact corresponding AFAS target. Follow each target to the public DKIM key. Compare authoritative results with recursive results after the relevant cache lifetime. A CNAME at a doubled hostname does not satisfy the correct owner. Check the complete SPF policy for duplicate records and evaluation errors, not just the presence of the AFAS term.

Once a sample reveals its envelope domain, query that domain’s SPF policy too. Query the real From subdomain’s DMARC policy where applicable rather than assuming all mail uses the root domain.

Check Profit status and delivered headers

AFAS exposes sender/domain status under Environment properties > AFAS Online > Mailserver AFAS Online. Its documentation describes a 12-hour checking cycle. Treat status as an operational clue, not a replacement for message evidence. Review each environment. AFAS status controls

After implementation is authorized, send a representative message through the actual workflow to a controlled external mailbox. Start with direct delivery, then test any important forwarding or gateway route separately. Use a non-sensitive test document rather than real payroll or customer financial information.

Inspect the receiving system’s trusted Authentication-Results, the visible From, Return-Path and each DKIM-Signature. Do not rely on an untrusted upstream authentication header. Authentication-Results trust boundary

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Accept the branded setup only when:

• The intended From address is present for that workflow.
• The intended branded DKIM signature has dkim=pass, the expected AFAS selector, and a d= domain aligned with From under the active adkim mode.
• SPF is checked for the actual envelope domain; its result and alignment are recorded separately.
• The receiver reports dmarc=pass for the intended From domain.
• Representative invoice, notification and other relevant sender variants have been checked, rather than assuming one environment-wide test covers every template.

A DMARC pass supplied by SPF does not excuse missing branded DKIM. Investigate SPF fail, softfail, permerror and temperror even when DKIM lets DMARC pass. For a direct-delivery SPF failure, inspect the connecting IP, actual envelope owner and complete policy; for forwarding, distinguish the forwarder’s IP from AFAS’s original hop.

Troubleshoot AFAS-specific failures

The request, credentials and domain-error cases are documented in the AFAS DKIM checklist. AFAS’s sent-email history helps correlate the sender and message type with the failure. Keep sensitive attachments and credentials out of support evidence.