Based on the bounce-back emails, the core issue is that your emails are being rejected because the sending domain, WORLDOFWALLPAPER.COM, is failing the DMARC authentication check.

The Problem

The error message, "550 5.7.515 Access denied, sending domain WORLDOFWALLPAPER.COM doesn't meet the required authentication level," explicitly states the problem. The receiving mail server, which in all three cases is an Outlook-based service (MSN, Hotmail), is checking your email's authenticity using DMARC and finding it fails. While SPF and DKIM both show as "Pass," DMARC fails because the domain alignment requirements aren't being met.

• DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that builds on top of SPF and DKIM. It tells the recipient's mail server how to handle messages that fail either of these checks.
• SPF (Sender Policy Framework) authorizes specific servers to send emails on behalf of your domain. The "Pass" result means the recipient server confirmed your email came from an authorized IP address.
• DKIM (DomainKeys Identified Mail) adds a digital signature to the email header. The "Pass" result means the recipient server verified this signature, confirming the email hasn't been tampered with in transit.
• DMARC Alignment Failure occurs when the "From" domain in the email header (the one users see) doesn't align with the domains verified by SPF or DKIM.

In your case, even though SPF and DKIM passed, the DMARC record for your domain likely has a policy that requires one of these checks to be "aligned" with the email's "From" address. This alignment is what's failing, causing the recipient's mail server to reject your message.

The Solution

To resolve this, you need to fix the DMARC alignment issue. This generally involves two steps:

1. Check your DMARC record: Use a DMARC record lookup tool to inspect the DMARC DNS record for your domain, WORLDOFWALLPAPER.COM. Look at the policy (p=) and reporting (rua=) tags.
2. Fix the alignment: The DMARC alignment failure is likely due to one of these reasons:
   • Subdomain mismatch: You may be sending from a subdomain (e.g., [email protected]) that isn't properly configured for SPF or DKIM, or a third-party sender is using a different domain.
   • SPF/DKIM misalignment: The domain in the email header's "From" field isn't the same as the domain in the SPF or DKIM record. For DMARC to pass, the domains must match, or the subdomain must be a sub-domain of the domain in the SPF or DKIM record.
   • "p=reject" policy: Your DMARC policy might be set to p=reject, which means any email that fails alignment is rejected outright.

The most straightforward way to solve this is to ensure your outgoing mail server (in this case, hMailServer) is correctly configured for DKIM signing. The DKIM signature must be added to the email header and use the domain WORLDOFWALLPAPER.COM (not hmailserver.com or any other domain). This will ensure the DMARC check passes by aligning the DKIM domain with the "From" address domain.

Once you've made these changes, you should verify the new settings using a tool that can analyze your email headers and confirm that the DMARC check passes before you send to a wider audience.

Based on the image you've provided from the MxToolbox SuperTool, here is a breakdown of the problem and the solution.

The screenshot shows the results of a DNS lookup for worldofwallpaper.com. The critical information is under the "Test" section:

• DMARC Policy Not Enabled: This is the key issue. The result says "DMARC Quarantine/Reject policy not enabled". This means your DMARC record is likely using a policy of p=none.

The Problem Explained

A DMARC policy of p=none tells receiving mail servers to perform the DMARC check but to take no action if it fails. The purpose of this policy is for monitoring and reporting. However, some receiving mail servers, like Microsoft's (Outlook/Hotmail/MSN), have their own stricter policies. When they see a DMARC record with p=none, they can still choose to reject the email if it fails their internal DMARC alignment checks, which is what's happening to you.

The bounce-back messages you received stated: DMARC= Fail 550 5.7.515 Access denied, sending domain WORLDOFWALLPAPER.COM doesn't meet the required authentication level.

This confirms that even though your DMARC policy is set to p=none, Microsoft's servers are still rejecting the emails because the domain isn't meeting their required authentication level. They are looking for a stronger DMARC policy to prove the email's authenticity.

The Solution

You need to change your DMARC policy from p=none to a more assertive policy to satisfy the requirements of servers like Microsoft's.

Here are the steps to fix this:

1. Modify your DMARC DNS Record: Access your domain's DNS settings (likely through your domain registrar or hosting provider). Find the TXT record for DMARC. It will look something like this: _dmarc.worldofwallpaper.com

2. Change the Policy: Edit the value of the TXT record. Change the p=none part to either p=quarantine or p=reject.

   • Recommended first step: Change p=none to p=quarantine.
     • p=quarantine: This tells receiving servers to place emails that fail DMARC in the spam folder or quarantine them. This is a safer first step as it gives you a chance to see if any legitimate emails are being affected without them being outright rejected.
   • Final goal: Change p=quarantine to p=reject after you are confident that all your legitimate mail is passing DMARC.
     • p=reject: This is the strongest DMARC policy and tells receiving servers to outright reject any email that fails DMARC. This is the ultimate goal to prevent malicious actors from spoofing your domain.

3. Add a DMARC pct Tag: To be extra cautious, you can also add a pct (percentage) tag to your record. This allows you to gradually increase the number of emails affected by the policy. For example, p=quarantine; pct=20 would only quarantine 20% of the emails that fail the DMARC check. You can increase this value over time.

New TXT Record Value (example): v=DMARC1; p=quarantine; rua=mailto:[email protected];

(Replace [email protected] with a valid email address to receive DMARC reports, which can help you troubleshoot any issues.)

Once you update your DNS record, give it time to propagate (this can take up to 24-48 hours, though often much faster). After propagation, your emails should no longer be rejected by Microsoft servers for this specific DMARC failure.

It's understandable to think SPF is failing because the email is being forwarded, but the error messages you're seeing point directly to a DMARC failure, even when SPF passes.

Here's the breakdown of why this is happening:

The Problem with Forwarding and DMARC

When an email is forwarded, a new email is created by the forwarding server and sent to the final recipient. The original email's From address, which is WORLDOFWALLPAPER.COM, is retained, but the email is being sent from a new, intermediate server.

• SPF Failure: If this intermediate forwarding server is not listed in the SPF record for WORLDOFWALLPAPER.COM, the SPF check would fail. However, the bounce messages you provided explicitly state Spf= Pass. This means either the forwarding server is authorized in your SPF record, or the recipient's mail server is not performing a strict SPF check.

• DKIM Failure: The original email likely had a DKIM signature from your hMailServer, but the forwarding server did not add its own signature. When the final recipient's server receives the forwarded email, the original DKIM signature might be broken or invalidated by changes made during forwarding. The bounce messages say Dkim= Pass, which means the DKIM signature is still valid, even with forwarding.

• DMARC Failure (The Real Culprit): DMARC requires SPF and/or DKIM alignment. This is where the forwarded email fails. DMARC alignment means the domain in the From address (WORLDOFWALLPAPER.COM) must match the domain that passed the SPF check or the DKIM check. With forwarding, the SPF check might pass for the forwarding server's domain, but it will not align with your WORLDOFWALLPAPER.COM domain in the From address. Even though the SPF check passed, the DMARC check for alignment failed.

The bounce message you shared clearly states: DMARC= Fail The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender.

This is a classic DMARC alignment failure, which is a common issue with forwarded mail.

The Solution

The ideal solution is to ensure your DMARC policy is set up correctly and that your original messages are authenticated strongly enough to pass even when forwarded. Since you can't control the forwarding server, you should focus on your own email authentication.

1. Set a DMARC Policy: Your MXToolbox check showed your DMARC policy is not enabled. As recommended earlier, change your DMARC record to p=quarantine or p=reject. This tells the receiving server that your domain is authenticated and that forwarded mail that fails alignment should be treated with a stricter policy. This is a counter-intuitive but often necessary step to get forwarded emails to pass. The receiving server is likely rejecting the email because your DMARC policy is not strict enough, and they are implementing their own, more restrictive, DMARC policy.

2. Add a From Address Rewrite (If Possible): If your email is being forwarded by a service you have control over, configure it to rewrite the From address to the forwarding service's domain. This would make the email look like it's from hmailserver.com and avoid the DMARC alignment issue. However, this is usually not an option with external forwarding.

3. Ensure DKIM Signing is Correct: Make sure your hMailServer is correctly signing all outgoing emails with a valid DKIM key for the WORLDOFWALLPAPER.COM domain. When an email is forwarded, the DKIM signature is often preserved, and if it's a strong signature, it can allow the email to pass the DMARC check even if the SPF record fails. The fact that the bounce messages say Dkim= Pass is a good sign. The DMARC check will pass if either SPF or DKIM align. If your DMARC record is set to a strict policy, the DKIM Pass will be enough to satisfy the receiving server's requirements.

Your analysis is correct; the issue is that your forwarded email is coming from a subdomain, and this is causing a DMARC failure due to a lack of alignment.

The Problem

The DMARC report shows that your email is passing both SPF and DKIM checks, but it's still failing DMARC because of domain misalignment.

• header_from: The email's "From" address is worldofwallpaper.com.
• SPF Alignment: The SPF check passes for k3.send.worldofwallpaper.com. While this is a subdomain of worldofwallpaper.com, the DMARC record's aspf tag is set to r (relaxed), which allows for this subdomain alignment to pass. So SPF is not the problem here.
• DKIM Alignment: The DMARC report shows two DKIM signatures: one from shared.klaviyomail.com and another from send.worldofwallpaper.com. The adkim tag in your DMARC record is set to r (relaxed), which means send.worldofwallpaper.com should also align.

However, the bounce messages you provided earlier explicitly state a DMARC failure. This indicates that despite what the report says, a specific mail server (like Microsoft's) is still enforcing a stricter policy. The most likely cause is that while the SPF and DKIM checks are technically passing, the domains are not an exact match to the header_from domain, which is what some mail providers require for a full DMARC pass.

The Solution

Even though your DMARC report shows SPF and DKIM passing, the fact that you're still getting bounce-backs means that your current configuration isn't sufficient. The solution is to ensure your header_from domain is used in all authentication checks.

1. Configure DKIM for the root domain: Make sure your email server is signing messages with a DKIM signature from worldofwallpaper.com, not a subdomain like send.worldofwallpaper.com or a third-party domain like shared.klaviyomail.com. This is what we discussed before, and it seems to have been implemented, but the DMARC report still shows the signatures from the subdomains. You may need to revisit your server configuration to ensure the header_from domain is used.

2. Adjust DMARC Policy: Your current DMARC policy is set to p=none. This tells receiving servers to perform DMARC checks but to take no action if a message fails. Some strict mail providers, like Microsoft, ignore this and will still reject the email if it doesn't meet their internal authentication standards. Change your policy to p=quarantine or p=reject. This will tell the recipient server to respect your DMARC policy and will satisfy the requirements of mail providers that require a stronger policy.

Once you change your DMARC policy, the DMARC alignment will become a bigger issue if not already fixed. Double-check your server configuration to ensure the header_from domain is being used for authentication.

If you're using Exchange DKIM Signer on Exchange 2019 and still experiencing DMARC failures, you should check the DKIM signing configuration for the worldofwallpaper.com domain within the Exchange DKIM Signer tool. The key issue is ensuring the email is signed with the correct domain to pass DMARC alignment.

Step 1: Verify the Configuration

1. Open Exchange DKIM Signer: Launch the Exchange DKIM Signer management console.
2. Select worldofwallpaper.com: Navigate to the domain list and select worldofwallpaper.com.
3. Check Private Key and Selector: Ensure the tool is configured with the correct private key that matches the public key you published in your DNS. Also, verify that the selector (e.g., dkimwow) is correct. A mismatch in either of these will cause the signature to fail validation.
4. Confirm Signing is Enabled: Make sure the signing is enabled for worldofwallpaper.com.

Step 2: Check the Mail Flow

1. Bypass your hMailServer: To isolate the issue, try sending an email directly from an Exchange user to a test address (like a Gmail account) without it going through the hMailServer.
2. Inspect the Headers: Check the full message headers of the test email. Look for the DKIM-Signature header.
   • Domain (d= tag): Confirm that the d= tag in the DKIM header is worldofwallpaper.com. If it's something else (e.g., argofield.co.uk), then the Exchange DKIM Signer is not correctly configured for this domain, or another process is interfering.
   • Result: Look for an "Authentication-Results" header. It should show dkim=pass for worldofwallpaper.com.

Step 3: Address Potential Conflicts

• Subdomain vs. Root Domain: Your DMARC report showed that some emails are being signed with a subdomain (send.worldofwallpaper.com). Exchange DKIM Signer needs to be configured to sign emails from the root domain, worldofwallpaper.com, to ensure proper DMARC alignment. If it's signing a subdomain, the DMARC check will likely fail on stricter mail servers.
• Third-Party Services: The DMARC report also showed a DKIM signature from shared.klaviyomail.com. This suggests a third-party service is also sending emails on your behalf. Ensure that the SPF and DKIM records for this service are correctly configured to align with your DMARC policy. You may need to create a DKIM key for this service as well.

Step 4: Final Solution

The most common reason for a valid DKIM record to fail is a mismatch between the private key on the server and the public key in the DNS. The easiest way to fix this is to:

1. Generate a new DKIM key pair specifically for worldofwallpaper.com using a reliable tool.
2. Update your DNS record with the new public key.
3. Update Exchange DKIM Signer with the corresponding new private key.

After these steps, your emails should be correctly signed, and DMARC should pass.

Since this issue only affects emails forwarded by Replyco, the problem is DMARC alignment, which is a known issue with email forwarding. You need to adjust your DMARC policy to be more relaxed.

The solution is to modify your DMARC DNS record for worldofwallpaper.com.

1. Change the DMARC Policy

Your current DMARC policy is likely set to p=none, but some mail providers (like Outlook/Hotmail) are still rejecting the emails because of the DMARC alignment failure. You need to change the policy to something that will work with forwarded mail.

The key to fixing this is to change the aspf (SPF Alignment) and adkim (DKIM Alignment) tags in your DMARC record to r (relaxed) if they're not already. This allows subdomains to align with the main domain, which is crucial for forwarded mail.

2. DMARC Record Adjustments

Go to your domain's DNS settings and edit the DMARC TXT record for _dmarc.worldofwallpaper.com.

• Change aspf and adkim to r: The record should explicitly state aspf=r and adkim=r. This allows a DKIM signature from send.worldofwallpaper.com to align with a From: address of worldofwallpaper.com.
• Leave p as none for now: The p=none policy tells receiving servers not to take action, which gives you time to monitor results.

The final DMARC record should look something like this:

v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:[email protected];

(Replace [email protected] with a valid email address to receive DMARC reports).

3. Implement the Change and Monitor

• Save the DNS record: Save the changes to your DNS. It may take a few hours for the changes to propagate.
• Monitor your DMARC reports: Keep an eye on the DMARC reports sent to your email address. The reports will show if the alignment is now passing for forwarded messages.
• Test again: Send a few test emails through the Replyco forwarding service to see if they successfully reach a variety of recipients, especially those at Outlook, Hotmail, and MSN.

By relaxing the DMARC alignment policy, you are telling mail servers that it's okay for the SPF and DKIM domains to be a subdomain of your main domain, which is what happens with forwarded email.

Based on your current DMARC record, you have correctly configured the adkim=r and aspf=r tags, which should allow forwarded emails to align and pass. The fact that the emails are still failing means there's another issue.

The problem likely lies with the p=quarantine policy and the receiving mail server's interpretation of your domain's reputation.

The Problem

While your policy is set to quarantine, some receiving mail servers (especially those with a low trust score for your IP address or domain) will interpret this as a reason to reject the message outright. The DMARC report you shared previously showed that while SPF and DKIM were passing for the subdomain, the email was still likely rejected because the domain's DMARC policy wasn't strong enough to override the receiving server's security checks.

It's a subtle but important distinction:

• The adkim=r and aspf=r tags tell the receiving server to relax the alignment rules, allowing forwarded emails to pass. You have this correct.
• The p=quarantine tag tells the receiving server to put the email in the spam folder. However, if the server's own internal filters and trust-score are low, they may choose to reject the email completely, even with this policy.

Essentially, the receiving server is saying, "I see your DMARC record, but because I don't trust you, I am going to reject this email instead of just quarantining it."

The Solution

The most common solution to this issue is to switch your DMARC policy to p=none for a short period. This allows you to monitor the DMARC reports without the risk of emails being rejected. Once you confirm that the DMARC reports show "pass" for forwarded emails, you can gradually increase the policy.

1. Change p=quarantine to p=none: In your DNS record for _dmarc.worldofwallpaper.com, change the policy.

   v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=0; adkim=r; aspf=r

2. Monitor DMARC Reports: After the DNS change propagates, monitor the DMARC reports you receive. The policy_evaluated section of the report will show if the emails are now passing without being rejected.

3. Adjust the Policy Back: After a few weeks of successful reports, you can safely move your policy back to p=quarantine. If emails are now successfully delivered, you've solved the problem.

This approach ensures that your DKIM and SPF records are correctly configured and aligned without the risk of emails being rejected by overly aggressive spam filters.

You are correct. Microsoft mail servers (Hotmail, Outlook, MSN) are known to treat a p=none DMARC policy as a non-compliant policy if the domain has a history of spam or a low sender reputation. Even with a passing SPF or DKIM check, they may still reject the message outright because they require a stronger policy (p=quarantine or p=reject) to be in place.

The Problem

The reason your forwarded emails are still failing is a DMARC policy enforcement issue on the recipient's side, not a technical alignment issue on yours. The DMARC= Fail message you received from Microsoft mail servers is a signal that your p=none policy is not considered strong enough to satisfy their security requirements.

The Solution

The solution is to change your DMARC policy to a stricter one. However, you cannot go directly to p=quarantine or p=reject with a forwarded email, as this will fail the DMARC alignment check. Instead, you need to use a subdomain for the forwarded emails that has its own, stricter DMARC policy.

1. Create a dedicated subdomain: Create a subdomain specifically for forwarded emails, such as forward.worldofwallpaper.com.
2. Configure the subdomain with a stricter DMARC policy: Create a DMARC record for this new subdomain with a p=quarantine or p=reject policy. This will satisfy the recipient's security requirements.
3. Configure Replyco to use the new subdomain: Configure Replyco to use the new subdomain as the From: address for forwarded emails.
4. Add a new DKIM record for the subdomain: If Replyco's forwarding service doesn't already have one, you will need to add a new DKIM record for the subdomain to ensure the emails are signed correctly.

By using a subdomain with a stricter DMARC policy, you will satisfy the recipient's security requirements while still allowing your forwarded emails to be delivered.

The image you provided shows an email from Replyco with the warning, "We can't verify that this email came from the sender so it might not be safe to respond to it." This warning is a direct result of a DMARC alignment failure, which is a common issue with forwarded mail.

Here's why this is happening:

• The Original Email: The initial email is from simoncooper@..., sent to [email protected].
• The Reply: The reply is sent by your team member at [email protected], but it's sent through Replyco's platform.
• The Forwarding: Replyco then forwards this reply back to the original sender, Simon Cooper. However, Replyco sends the email "on behalf of" your domain. The email's From: address appears as [email protected], but the actual sending server (and the Return-Path header) is a Replyco address, such as [email protected].
• The DMARC Failure: The recipient's mail server receives an email that claims to be from worldofwallpaper.com but is actually sent from an replyco.email address. This is a clear mismatch. Even if your SPF and DKIM records are configured correctly, the DMARC protocol flags this as an alignment failure. The recipient's mail server then displays a security warning because it can't definitively confirm the email's origin.

Solution

The only way to solve this is to ensure that emails sent through Replyco align with your DMARC policy.

1. Configure Replyco to use your domain: You need to configure Replyco to send emails directly on behalf of worldofwallpaper.com. This typically involves adding specific DKIM and SPF records provided by Replyco to your domain's DNS. This will allow Replyco's servers to send mail for you without causing a mismatch.

2. Add a DMARC policy: You should have a DMARC policy for worldofwallpaper.com with p=quarantine or p=reject. This will tell recipient mail servers what to do with unverified emails.

3. Adjust DMARC tags: Your DMARC record should use a relaxed policy for both SPF and DKIM (aspf=r and adkim=r). This allows a subdomain (like Replyco's) to align with your root domain.

By following these steps, you will allow Replyco to send emails on your behalf without triggering the DMARC alignment failure warning.

Perfect, thanks for the screenshots - that clears things up nicely.

You already have a single mailbox called World of Wallpaper - Customer Service with:

• Logon account: [email protected]
• Primary SMTP address: [email protected]
• Additional addresses: [email protected], [email protected]

That means this is already the right account to authenticate with for Replyco. No need to bolt on extra Send-As permissions - the From address ([email protected]) is literally the default SMTP address of the same mailbox.

Why it's still failing

From your earlier protocol log:

Inbound authentication failed because the client ARGOFIELD\info.WOW doesn't have submit permission.
User Name: [email protected]

So Replyco is authenticating as the local UPN ([email protected]) instead of the SMTP-style identity ([email protected]).

Exchange sees that as a mismatch you're logging in with one identity, then trying to send as another 5.7.60 error.

Fix

In Replyco's SMTP settings, set:

• Server: mail.argofield.co.uk
• Port: 587
• Security: STARTTLS
• Username: [email protected] (or, if you prefer, update the UPN in AD so this account's logon name is also [email protected])
• Password: the AD password for this account
• From: [email protected]

Why this works

• Using the public SMTP address as the username makes the authentication identity match the mailbox's primary SMTP.
• Because that mailbox already owns the [email protected] address, Exchange won't complain about "Send As" rights.
• Relay will succeed because the account is authenticated on the Client Frontend 587 connector.

One-liner if you want to clean it up at the AD side (so the user can log on both ways):

Set-User "info.WOW" -UserPrincipalName [email protected]

(but only after you add worldofwallpaper.com as an alternative UPN suffix in AD Domains and Trusts - otherwise it will reject it).

Do you want me to give you the exact steps to add worldofwallpaper.com as a UPN suffix in AD, so you can safely flip this account's logon from .local to .com? That way Replyco (and any other external service) always uses the real email address for login.