Inky Phish Fence SPF, DKIM and DMARC setup, step by step

For a domain whose mail is processed through INKY's inline route, merge exists:%{i}._spf.inkyphishfence.com into its existing SPF policy while retaining Microsoft 365, Google Workspace and every other legitimate sender. Configure custom-domain DKIM in the underlying mail platform, then check a message at its final recipient. INKY's Routing page checks published DNS; a “Key published” result does not prove that a delivered message has a valid, aligned signature. INKY SPF instructions · Routing authentication checks

No customer account, customer DNS configuration or mail delivery was tested. Follow the applicable licensed route and account-generated values.

Scope: Phish Fence inline processing, not an email marketing sender

INKY currently describes Phish Fence as its email-security engine for inbound, internal and outbound analysis. Its Microsoft 365 installation configures tenant routing, and its Google Workspace installation has separate gateway, relay and content-compliance steps. Features and available routing can differ by deployment and license. Phish Fence scope · Microsoft 365 installation · Google Workspace installation

This guide addresses domain authentication for that inline mail path. It is not a complete installation or permission-grant guide. A journal-only analysis feed, an inbound threat verdict or the mere presence of an INKY license does not establish an outbound sending path.

Do not change another organization's SPF because INKY scans its inbound mail. DNS authorization here concerns domains you control and the supported route sending or relaying on their behalf.

Establish who sends, who signs and who changes DNS

Before editing a record, have the mail administrator document:

• The tenant, INKY team, configured domains, protected users and actual installed route.
• Whether each mail stream returns from INKY to Microsoft/Google or reaches another receiver through a different approved relay path.
• The visible From domain, actual SMTP envelope domain, and service expected to sign with the customer domain.
• The authoritative DNS zone, existing SPF policy, active DKIM selectors and applicable DMARC policy.
• Any footer, banner, signature-management or link-rewriting step that can modify signed content.
• A controlled external test mailbox, representative new-message/reply/forward samples and a rollback owner.

Retain platform sending authorizations even when INKY is inline. The same domain may also send through application services, failover routes and unprotected users. One domain's SPF does not automatically apply to every subdomain.

Use the underlying mail platform's authorized administrative access for DKIM. Do not grant broad partner access, change tenant permissions or bypass security controls merely to follow an authentication checklist. Installation permissions and mail-routing changes need their own approved deployment plan.

Add INKY to the existing SPF policy

SPF checks the connecting IP against the SMTP MAIL FROM domain, or the applicable HELO-derived identity when the envelope is empty. It does not directly authenticate the From address a person sees. Confirm the evaluated identity before editing DNS. SPF identity rules

Preferred mechanism

INKY documents this literal mechanism:

exists:%{i}._spf.inkyphishfence.com

Add it to the domain's one existing SPF TXT policy, ahead of its terminal all mechanism. Preserve the existing legitimate sender terms and the approved -all, ~all or other policy ending. Do not publish the mechanism as a separate second SPF record. If the policy uses redirect= rather than a terminal all, have its owner integrate the new authorization without adding an all that would disable the intended redirect behavior. INKY's current SPF procedure · SPF all/redirect processing

Any all mechanism makes redirect inoperative, regardless of that mechanism's qualifier. Qualifiers specify SPF results, not deterministic inbox placement or receiver rejection. Preserve the owner's intentional policy; changing a qualifier is not a repair for DNS or syntax errors. SPF all processing

These examples apply only to the stated starting policies. They are not replacements for a multi-sender organization's full record.

If the existing policy authorizes only Microsoft 365 and already ends in -all:

Before: v=spf1 include:spf.protection.outlook.com -all
After: v=spf1 include:spf.protection.outlook.com exists:%{i}._spf.inkyphishfence.com -all

If the existing policy authorizes only Google Workspace and already ends in ~all:

Before: v=spf1 include:_spf.google.com ~all
After: v=spf1 include:_spf.google.com exists:%{i}._spf.inkyphishfence.com ~all

If no SPF policy exists, inventory all legitimate senders first. An INKY-only policy would omit Microsoft, Google or another service whenever its IP is evaluated directly. Do not assume the vendor's single-sender example fits your tenant.

Alternative when the DNS editor rejects the macro

If your DNS interface cannot store the literal %{i} expression correctly, INKY documents this pair as an alternative:

include:spf-ipw.inkyphishfence.com
include:spf-obx.inkyphishfence.com

Merge both into the existing policy instead of the INKY exists term, retaining all other authorized senders and the policy ending. Do not add just one, and do not routinely add both methods together. Verify the full recursive lookup cost before saving. Ask your DNS host whether it can preserve standard SPF TXT syntax before choosing a fallback. Documented fallback

Four technical details that prevent misleading SPF checks

The literal vendor mechanism is supported, but several explanations on its page need the SPF standard's more precise definitions:

1. %{i} is not reversed IPv4. For the documentation IP 192.0.2.10, it expands to 192.0.2.10. %{ir} would reverse the parts. Keep INKY's literal %{i}; do not “correct” the record to %{ir}.
2. exists checks for an A-record answer. It does not succeed merely because any DNS record type exists at the expanded name. The returned A address need not equal the sending IP.
3. 255 octets is a single TXT character-string limit. One TXT record can contain several strings, concatenated without inserted spaces. Splitting a long value must preserve required spaces; creating two separate SPF policies is not the solution.
4. Count recursive processing, not just visible includes. exists is a lookup-causing term. Nested includes and redirects also consume the ten-term budget when evaluated. The fallback does not have a universal fixed three-lookup cost.

These distinctions come from RFC 7208 sections 3.3, 4.6.4, 5.7 and 7.3. Evaluate representative actual sending paths, including IPv6 where used, with a standards-aware SPF validator. Also investigate excessive void lookups and DNS failures. Do not silence errors with +all, remove active senders without approval or copy today's provider IP ranges into an unmaintained flattened policy.

Enable DKIM in the underlying mail platform

INKY's Routing documentation instructs administrators to enable DKIM and publish keys in the mail platform. It checks common platform selectors and can report that it has no selector to try. That is not documentation of an INKY-generated customer DKIM key or a universal INKY selector. INKY's DKIM check boundary

Microsoft 365 custom-domain DKIM

The sending domain must already be added to Microsoft 365, and the administrator must have the permissions needed to manage its DKIM settings.

1. In Microsoft Defender, open Email & collaboration > Policies & rules > Threat policies > Email authentication settings, then the DKIM tab.
2. Select the exact custom domain. For a new domain showing NoDKIMKeys, follow Microsoft's initial enable attempt to generate its configuration. The documented sequence exposes the required CNAMEs and can show CnameMissing until DNS is published. Do not disable an already working domain merely to restart setup.
3. Copy the account's actual Publish CNAMEs values and publish both records. The owner labels are selector1._domainkey and selector2._domainkey under that sending domain; the targets must come from the tenant.
4. After DNS is detected, enable Sign messages for this domain with DKIM signatures. Confirm that the status reports signing for the domain, then test through the actual INKY route.

Microsoft's newer target format includes a dynamically assigned partition component. Older domains may use an onmicrosoft.com target instead. Do not construct targets from another tenant's example or assume the old format for every account. Microsoft's complete DKIM procedure

Google Workspace custom-domain DKIM

Use an authorized super administrator for key generation and the required Gmail Settings privilege. Google notes that a newly enabled Gmail organization can need 24–72 hours before key generation is available.

1. Open Apps > Google Workspace > Gmail > Authenticate email and select the actual sending domain.
2. If signing is not already correctly configured, use Generate New Record. Select 2048 bits when supported by the DNS host. Use a non-conflicting selector; do not overwrite another sender's google selector.
3. Publish the generated TXT owner and public key exactly as supplied. Create one TXT record, using multiple character-strings if required by the DNS interface, rather than separate key records.
4. After public DNS is correct, return to that domain and choose Start authentication. Confirm the signing status and verify a message delivered to another mailbox through the INKY route.

Do not regenerate a working key without a rotation plan. If your domain's supported integration already creates the key and DNS automatically, inspect that configuration and follow Google's activation/verification branch rather than duplicating it. Google's DKIM setup and prerequisites

If a long Google DKIM TXT value needs component strings, keep them inside one logical record: receivers concatenate those strings without inserted spaces. Preserve the complete key and tags; do not create independent competing key records. DKIM TXT concatenation

Only the public key belongs in DNS. Never place a private key or administrator credential in a record or public troubleshooting post.

DNS safeguards for platform DKIM

For an illustrative owner selector1._domainkey.news.example.com, use selector1._domainkey.news in an automatically suffixed example.com zone, or selector1._domainkey in a delegated news.example.com zone. Verify the actual final owner and authoritative zone. Preserve legitimate _domainkey or other child-zone NS delegation and publish in that authoritative child zone rather than deleting delegation records. If _domainkey.news.example.com is itself delegated, the same full owner uses relative selector1 in that zone. Do not use @ or overwrite existing selector data. A required CNAME cannot coexist at the same owner with TXT, A, AAAA, MX or another CNAME; resolve collisions with their owners rather than deleting active data. DNS alias rules

For Microsoft's CNAMEs, use DNS-only where proxying is available. Set per-record Flatten off where available and ensure zone-wide flatten-all does not suppress the required aliases. Cloudflare documents that its flatten-all setting can suppress CNAME verification and cannot be overridden per record. Do not change that shared setting without assessing other dependent records; obtain a narrow supported solution. If mandatory apex or same-zone flattening prevents the literal CNAME answer, stop and coordinate a supported design with the DNS and mail administrators; do not invent a per-record bypass or remove shared delegation. Google-generated TXT keys are not CNAMEs and should not be converted to aliases. CNAME flattening behavior

Keep DMARC policy intact

DMARC needs a passing SPF identity or DKIM signature that aligns with the visible From domain. Strict alignment requires exact equality; relaxed alignment uses the applicable organizational-domain relationship. A DKIM signature from a provider-owned domain may pass cryptographically without aligning to your brand. DMARC alignment

For a hypothetical visible From news@example.com, a passing intended-platform signature with d=news.example.com aligns in relaxed mode but not strict mode. A passing d=example.com aligns in both. These are identity examples, not measured tenant results. Preserve the current alignment policy rather than loosening it to fit an untested route. Identifier alignment

Read the existing _dmarc record and applicable parent policy. Preserve enforcement, subdomain inheritance, adkim, aspf and reporting destinations. Do not lower a domain from p=reject to p=none, disable DKIM or bypass INKY to make one test appear successful.

Only when there is no direct or applicable inherited policy, and the domain owner approves an appropriate monitoring plan, a first-policy example is:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none

For _dmarc.example.com in the example.com zone, the relative owner is _dmarc. For a child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in an authoritative delegated news.example.com zone. Publish only the owner chosen by the policy administrator.

This is not a replacement for an existing or inherited policy. It requests neither DMARC rejection/quarantine nor aggregate reports by itself. Add rua only for an approved destination. If that destination is in a different Organizational Domain from the discovered policy domain, the report-generating receiver must check DNS authorization provided by the report-destination operator. A destination within the same Organizational Domain is excepted; a different hostname alone does not make it external. Report authorization and same-domain exception Approve the metadata sharing, retention and access first; message-level failure reports require separate privacy consideration. Aggregate reporting authorization

Validate DNS, INKY status and the final received message

1. Query the actual published names

These commands are examples. Replace the domain and selector with your account's values; do not assume every Google domain uses google or every sending identity is the apex.

dig TXT example.com
dig CNAME selector1._domainkey.example.com
dig CNAME selector2._domainkey.example.com
dig TXT selector1._domainkey.example.com
dig TXT google._domainkey.example.com
dig TXT _dmarc.example.com

Run only the DKIM branch applicable to your platform. Expect one SPF policy containing all approved senders and the selected INKY authorization. A Microsoft DKIM CNAME should match its tenant-generated target and resolve to a public key; a Google DKIM TXT should match its generated public key.

Compare authoritative and independent recursive DNS when results differ. Inspect full response status, not just blank short output. A missing record, a cached old answer, a timeout and SERVFAIL are different findings. Account for positive and negative caching rather than waiting an arbitrary number of hours without checking.

A macro-aware SPF evaluation needs the actual client IP and SMTP identity. Querying the literal name %{i}._spf.inkyphishfence.com is not a substitute for expansion and does not validate the real path.

2. Refresh the INKY authentication check

Open Admin Center > Routing and use Check again on the domain's Email authentication row. Check the displayed timestamp. INKY distinguishes missing or multiple SPF policies, incomplete authorization, SPF evaluation errors, published DKIM keys and DMARC record status. A selector it does not know is a discovery limitation, not proof that the domain lacks DKIM. Routing status meanings

Resolve a missing or partial INKY SPF authorization, but do not interpret a green DNS row as an end-to-end message test. For Microsoft 365, the installation checklist and the separate routing Setup Status also answer different questions. Microsoft installation versus route status

3. Inspect trusted final-receiver results

Send innocuous, authorized samples for a new outbound message, a reply, a forward and each materially different configured route. Include aliases, subdomains and application paths when used. Obtain the original message source at a controlled external recipient after all content-modifying hops.

Record the From domain, envelope/Return-Path, receiving connection IP, SPF result and identity, every DKIM d=/s= and result, and the receiver's DMARC result. Compare with trusted mail-platform and INKY traces where needed.

Use results generated inside the actual receiving service's known processing boundary. Confirm with its documentation or administrator how it removes or marks externally supplied Authentication-Results before relying on those fields. Header position alone is not proof. An attacker can insert Authentication-Results using a plausible authserv-id. If the receiving service cannot distinguish or remove untrusted fields, use an independent trusted mailbox or receiver trace, not a matching header string as proof. Authentication-results trust boundary

Accept the custom-domain configuration when the intended mail-platform DKIM signature passes and aligns at the final recipient and DMARC passes. A generic DMARC pass through SPF alone does not prove that DKIM survived the route. A rewritten provider-owned From is not successful authentication of the intended brand. Inspect actual SPF independently: resolve unexpected fail, softfail, temperror or permerror even if DKIM supplies the DMARC pass.

If a legitimate forwarding path changes the envelope or connecting IP, analyze that path separately rather than authorizing every forwarder. Authentication pass does not establish that content is harmless or guarantee inbox placement.

Troubleshooting INKY-related authentication failures

INKY documents banner removal for replies and forwards, and Google explicitly warns that outgoing gateways can interfere with DKIM when they modify messages. Changes to signed content can invalidate a signature under DKIM's canonicalization rules. Work with the mail administrator and INKY on a supported route that preserves or correctly reapplies the intended signature after modifications; do not assume that a particular signing order is available in every deployment. Phish Fence processing · Google gateway caution · DKIM verification

A user-posted report about DKIM and banner removal is not proof of a universal current INKY defect. Reproduce the issue with controlled samples and current tenant traces before assigning a cause.

For interpretation of a cryptographic pass versus policy alignment, see EmailAuth's raw DKIM versus aligned DKIM guide. Changing -all to ~all does not repair a syntax or DNS-processing error.

Keep original messages in restricted storage and redact unnecessary addresses, message IDs and content before sharing evidence. If the new route fails, pause its rollout and restore only approved deployment changes, without removing unrelated sender records or creating broad security exceptions.