Aruba SPF, DKIM and DMARC setup, step by step

For the ordinary Aruba Hosting e Domini email configuration documented here, authorize Aruba with include:_spf.aruba.it in the domain’s single SPF policy and check the public DKIM TXT record at a1._domainkey.YOUR-DOMAIN. Compatible Aruba email services sign outgoing messages automatically when the corresponding configuration is available. There is no separate signing switch in this procedure. Finish by checking a controlled external message, not just the DNS record. Aruba SPF instructions and current DKIM instructions.

This guide covers existing custom-domain Posta mailboxes using Aruba’s documented a1 signing configuration and Aruba-authoritative DNS. It does not cover PEC, Cloud or self-managed servers, another mail provider, a personal @aruba.it address, or an account that supplies a different signing configuration. It does not move your mail or DNS hosting.

The current Aruba pages do not establish a publication or update date. No customer account, DNS change or message test was performed for this article.*

Check the service, access and existing records

Aruba’s Posta FAQ includes domain email with its Hosting, WordPress, website, e-commerce and Dominio con email offerings. That list does not establish that every Aruba-branded service uses the same DKIM key. The DKIM procedure itself says compatible services and identifies a1 for the configuration it describes. Confirm that this is your native mailbox service before copying the record. If your current account instructions or working signatures use a different configuration, reconcile the difference with Aruba rather than replacing it. Posta service and access distinctions.

You need authorized access to the domain’s Aruba control panel and a mailbox or approved application that actually sends through this native mail service. Aruba account access, postmaster access and ordinary mailbox Webmail credentials serve different purposes. A mailbox login alone is not permission to edit the domain’s DNS.

Before making changes:

• Confirm the authoritative nameservers and whether a child zone or _domainkey namespace is separately delegated. Registrar ownership alone does not establish DNS authority.
• Save the relevant current TXT records, selectors, delegations, TTLs and effective DMARC policy, including a parent policy inherited by the From domain.
• List all legitimate senders sharing the domain, their visible From addresses, actual SMTP envelope domains and outgoing routes. Include independent website, billing and marketing services.
• Agree with the mail/application and DNS owners which narrowly scoped changes, temporary pause and restoration are authorized. Keep a before-change record and preserve concurrent work by other administrators.

Do not change inbound MX, nameservers, DNSSEC, credentials or spam-filter settings to complete this task. If another sender is Microsoft 365, configure its separate route using the Microsoft 365 SPF and DKIM guide, rather than treating Aruba’s authorization as coverage for it.

Configure SPF without replacing other senders

Aruba publishes this example for a domain sending through its mail service:

v=spf1 include:_spf.aruba.it -all

Use it as a complete policy only when Aruba is the only authorized sender at the evaluated owner and the domain owner approves that policy. For a multi-sender domain, add the required Aruba mechanism to the existing single policy, preserving other legitimate authorizations and its approved qualifier. Do not add a second TXT record beginning v=spf1. Unrelated verification TXT records can remain. Aruba’s published SPF example.

SPF checks the SMTP MAIL FROM domain, commonly reflected in the received Return-Path, not automatically the visible From. A null reverse-path uses the relevant HELO identity. Inspect the actual native route before deciding which domain’s policy is being evaluated. A child envelope domain does not inherit the parent’s SPF, and editing your apex cannot change a provider-owned envelope domain’s policy. SPF identity rules.

Preserve existing ip4, ip6, include, a and mx terms only after confirming their legitimate use. An a mechanism authorizes the applicable address records; mx authorizes addresses of the applicable mail exchangers. Those authorizations can change when web or inbound-mail infrastructure changes. Neither mechanism is required by Aruba’s example, so do not add them merely because another tutorial includes them.

SPF permits at most ten evaluated DNS-query-causing terms across nested processing, including include, a, mx, ptr, exists and redirect. This is not a limit of ten includes or ten DNS packets. Check the whole evaluated tree before merging another sender. Also, an all mechanism makes redirect inoperative: adding Aruba followed by -all to a redirect-based policy can silently discard its existing authorization path. Have the DNS owner reconcile that policy deliberately. Lookup limit and redirect behavior.

-all, ~all and ?all produce different SPF results for unmatched sources. They do not guarantee rejection, delivery or inbox placement. Aruba’s separate discussion of inbound SOFT checking is not an instruction to change receiving filters as part of outbound authentication.

Publish the correct Aruba DKIM public record

First inspect the existing record and a recent authorized native-mail header. Aruba says signing is automatic for compatible services when the corresponding configuration is available. It specifically directs domains activated before February 2024, when the required record is missing, to add the record. This does not mean every older domain is missing DKIM or that a working key should be replaced. Current Aruba DKIM procedure.

For the documented a1 configuration:

• Type: TXT.
• Full owner: a1._domainkey.example.com, replacing example.com with the applicable signing domain.
• Value: the complete public record published by Aruba for that configuration, including the tags before p=.

The current first-party value checked for this article is:

v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoOhAWzBuKQYXU6E3E9efq+DPvtkkvWPg3EtB+BT2cTrMGh6Xy00mXfPi/EzubRpbhHpv3b3k1d65Vyhmpp5O3HzTQyzIqYMMF5iF5y05D5aEux3pj/i1g5LkAOFE0Xdf+wnI8zppP2jP7IV4bwKPr1OnBqOjs8hfBWSEGaCSFD/aVbOdNldHiwSalzDL38E+IcT0KQB+BdutC2T9B5idcSPaBY57sC4hq31wpBlgNcYpIMDxOQN+E9E+TbgnlJYCOYsD5S0amYFivcJObjSGpdstMBfaM1ox5iEQVpEhLz5cwgohjrMst2us7G9eHZ6p2jR7X+/yTP8ryAAywzMJ5wIDAQAB

Before publication, compare the entire value with the current official record and your actual service configuration. This is Aruba’s published public key, not a customer screenshot or a private key. If the official record changes or your service supplies a different one, stop and establish the correct configuration before editing. Do not generate a replacement key yourself or upload a private key to follow an older guide.

Copy all characters without truncation, leading/trailing spaces or an added domain suffix in the value. A DNS provider may encode a long TXT value as several quoted character strings within one record. Those strings concatenate into one logical value; they are not separate DKIM keys or separate TXT records. Compare the reconstructed value, not merely the first displayed string. DKIM public-key syntax.

A DNS record makes the verification key available. It does not prove that the native service signed the message or that the signature aligns with your From domain. Those checks come after publication.

Enter TXT records in Aruba’s DNS panel

Use the current documented navigation: open the domain’s control panel at admin.aruba.it, then Dominio > Gestione DNS e Name Server. Aruba notes that a Redirect-only service may not show this menu. Do not purchase an upgrade or move a service just to make the menu appear; establish the correct service and authorized DNS administrator. DNS-panel access.

For a missing, approved record:

1. Select Aggiungi record.
2. Choose TXT (Text).
3. Fill Nome host for the intended owner. Aruba documents a blank field for apex SPF, a full DKIM hostname such as a1._domainkey.example.com, and a full DMARC hostname such as _dmarc.example.com.
4. Paste the complete string into Valore, then choose the agreed TTL.
5. Select Aggiungi.

For an existing record, use its Modifica action, make only the approved change, then select Modifica to confirm. Do not add a duplicate policy to avoid editing the existing one. Pianifica operazione deliberately schedules a future date/time; a scheduled record is not published immediately. Aruba’s TXT add/edit procedure.

Map full owners to the actual authoritative zone

The Aruba instructions above use full DKIM/DMARC names. Where another authorized DNS interface expects a relative label, subtract the actual zone suffix exactly once. These are mapping examples, not permission to change providers or claim subdomain-mail entitlement:

• For signing domain example.com, full DKIM owner a1._domainkey.example.com is relative a1._domainkey inside example.com.
• If an approved service signs as news.example.com, full owner a1._domainkey.news.example.com is relative a1._domainkey.news in the parent zone, or a1._domainkey in a separately delegated news.example.com zone.
• If _domainkey.news.example.com is separately delegated, that same full owner is relative a1 in the delegated namespace. A record added to the parent beneath that delegation will not replace the delegated authority’s answer.
• SPF at news.example.com is relative news in the parent zone or the root/blank label in its own child zone. SPF at example.com uses Aruba’s documented blank apex input.

Preserve existing NS delegations and coordinate with their administrator. If the signing namespace is outside the Aruba authority covered by this procedure, stop rather than delete its delegation or pretend an Aruba-panel edit publishes there. Inspect the resulting full owner to avoid example.com.example.com.

This native configuration uses TXT, not DKIM CNAME aliases. Do not convert its public key to a CNAME or add proxy/flattening settings. If the intended TXT owner already has a CNAME or an unexplained different key, resolve its ownership and dependencies before changing it.

Preserve DMARC and approve any first policy

Check TXT at _dmarc of the actual visible From domain and determine whether an applicable parent policy is inherited. Preserve any existing direct or inherited policy, including p=none, and its approved report recipients. Do not create a child monitoring override merely to weaken inherited enforcement. DMARC policy discovery.

Only when no applicable direct or inherited policy exists, and the domain owner approves an initial monitoring policy and a report-review plan, a first TXT value can be:

v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-ADDRESS

Replace the entire placeholder with a functioning, authorized report address. Monitoring does not request quarantine or rejection. Do not paste an arbitrary third-party mailbox or add forensic reporting as an unnoticed side effect.

For From domain example.com, publish one TXT at full owner _dmarc.example.com; its relative label is _dmarc in that zone. For From domain news.example.com, full owner _dmarc.news.example.com is relative _dmarc.news in the parent zone or _dmarc in a delegated child zone. Aruba’s documented Nome host input uses the full hostname. Check the actual resulting name before saving.

Compare the Organizational Domain of the report destination with the Organizational Domain of the domain where the policy was found, not automatically the message’s From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone is not the boundary. RFC 9990 section 4. Separately obtain the domain owner’s permission to share report data, with appropriate recipient access and retention. Protocol authorization does not replace that privacy decision.

Treat enforcement as a separate all-sender decision. RFC 9989 section 7.4 requires valid DKIM signatures for mail from domains publishing p=reject and explains the importance for indirect mail flows. Review legitimate forwarding and mailing-list paths before enforcement; one direct Aruba test does not establish domain-wide readiness. Indirect email and DKIM requirements.

Verify DNS and the actual native-mail route

Query the authoritative servers and an independent recursive resolver. Replace the example domain before using these read-only queries:

dig TXT example.com
dig TXT a1._domainkey.example.com
dig TXT _dmarc.example.com

Compare the full answers with the approved records and any inherited-policy lookup. A recursive result may remain cached until its relevant TTL expires. Record when the authoritative answer became correct, rather than repeatedly changing a correct record while waiting for caches. There is no universal 72-hour completion guarantee.

Next send harmless, synthetic content through the actual native Aruba mailbox route to a controlled, valid external test inbox. Test each used Webmail, mail-client or authorized application path separately; do not trigger real customer mail, purchases or password disruption. A website that uses another SMTP service is a different route, even if its From address belongs to this domain. Aruba’s procedure explicitly calls for an externally received message and its complete headers. Provider verification steps.

Use only authentication results generated inside the receiving service’s known processing boundary. Establish how that service removes or treats externally supplied Authentication-Results, using its documentation or administrator. Header position and a familiar authserv-id string are not enough: ignore attacker-supplied or otherwise untrusted result fields. Authentication-Results security.

Record the unchanged approved From address, actual MAIL FROM/Return-Path domain, final connecting source, SPF result, intended DKIM d= and s=, DKIM result and trusted DMARC result. For d=example.com; s=a1, the key lookup is a1._domainkey.example.com. Aruba’s explanatory example currently pairs a different lookup domain with its example signature; derive the lookup from the actual d= and s= instead of copying that mismatch. DKIM selector lookup.

Completion requires the intended Aruba signature to pass, its d= domain to align with the unchanged intended branded From under the effective policy, and trusted receiver dmarc=pass. An unrelated passing signature, a rewritten provider From or DMARC passing through SPF alone does not prove this DKIM setup works. Relaxed alignment compares Organizational Domains; strict alignment requires the relevant domains to be identical. No universal custom envelope or strict alignment is promised by this setup procedure. DMARC alignment.

Troubleshoot and recover narrowly

SPF fail or softfail: compare the actual connecting source and envelope domain with the effective policy. Check whether the message used Aruba’s native transport or another service. Authorize only a legitimate required source; do not broaden SPF to make a test pass.

SPF permerror: inspect duplicate policies, syntax and the nested DNS-term budget. SPF temperror: investigate DNS availability or temporary resolution failure, then retest before rewriting correct authorization. SPF none or neutral: identify the evaluated owner and whether a missing policy or deliberate ?all explains the result. Diagnose SPF independently even when aligned DKIM supplies DMARC pass.

DKIM is absent: confirm the actual service and outgoing path. The documented native configuration is automatic, so do not invent an Enable button or substitute a locally generated key. Ask Aruba to reconcile a missing expected signature after the DNS and service identity are confirmed.

DKIM fails or the key is missing: compare actual d=/s=, full owner, authority, complete TXT value and scheduled-operation time. Check for truncation, duplicated suffixes or a conflicting record. If DNS is correct, compare direct and downstream routes for changes to signed content.

DKIM passes but DMARC fails: compare the signature identity with the unchanged From and effective alignment settings. Adding Aruba’s SPF mechanism cannot repair an unaligned DKIM identity by itself.

A DNS edit caused disruption: follow the pre-agreed recovery plan with the mailbox/application and DNS owners. Pause only affected sends when approved, and restore only the exact approved prior configuration while preserving concurrent changes. Keep old selectors needed by queued mail or other services through a provider-agreed transition. Stop or migrate dependent senders before retiring records. Retest after a domain, service, account, DNS authority, key or outgoing-route change. Do not reset an entire zone or change MX to undo an authentication-only edit.

Sources and verification limits

The configuration above follows the complete current Aruba DKIM, SPF, TXT editor, DNS access and Posta FAQ bodies. Those pages supply prose instructions, not substantive linked UI screenshots. Account eligibility, active DNS, actual sender identities and delivered-message results still require authorized checks in your environment.