Authenticate 360degreelogicalmktg.com for transactional email

💡 Why bother?

Imagine you receive a letter that looks like it's from your bank, but the return address on the envelope is from some random P.O. box you've never seen. You'd be suspicious, right? That's exactly what happens to our portal emails today. The email arrives at Gmail, but Gmail looks at the return-path and sees "brevosend.com" — not our domain. It's not necessarily spam, but Gmail's filters give it a yellow flag.

After this setup, our emails will carry a DKIM signature — a cryptographic stamp that says "this email is genuinely from 360degreelogicalmktg.com". Gmail verifies the stamp by checking a public key we'll publish in DNS. If the stamp matches, Gmail trusts the email. That's the whole game.

This is not optional before real brand clients sign in. Their corporate spam filters are far stricter than personal Gmail. Without domain authentication, our magic-link invites won't reach them at all.

💡 Why Hostinger and not somewhere else?

When you bought the domain name 360degreelogicalmktg.com, you bought it through Hostinger. They're the registrar — the official keeper of that domain's records. Even though our website runs on a server (the VPS), the "phonebook" that tells the rest of the world how to reach our domain lives at Hostinger.

That phonebook is called DNS (Domain Name System). And Hostinger's panel for editing it is called hPanel. We verified your nameservers point to ns1.dns-parking.com and ns2.dns-parking.com — these are Hostinger's default. So yes, you manage DNS at Hostinger.

💡 Why five records?

Think of these as five different signs you're posting at your domain's front gate, each answering a different question:

Record 1 (brevo-code): "Yes, the person who created the Brevo account really does own this domain." It's a one-time ownership proof.

Records 2 & 3 (DKIM): "Here are our public signing keys. If you receive an email signed with the matching private keys, you can trust it's really from us." Two keys for redundancy.

Record 4 (SPF): "These are the only servers allowed to send email pretending to be us." We're adding Brevo to the list (Google is already there).

Record 5 (DMARC): "Here's our policy if an email fails the above checks. For now, just monitor — don't actually block anything."

💡 Why these are dangerous to edit

The MX record tells the rest of the world where to deliver mail addressed to your domain. Yours currently routes everything to Google — that's your business Gmail. If you edit it, incoming email stops working immediately across the whole company. Brevo has nothing to do with this; Brevo is only about sending, not receiving.

The A and AAAA records point your domain name to a specific server IP address — the server that hosts your website. If you edit those, the website goes down. Again, unrelated to email.

💡 What's "dig" and why use it?

dig is a command-line tool built into every Linux system. It directly asks the public DNS system "what records exist for this name?" without any caching layer in the way.

This is how you confirm that DNS propagation is complete. Saving in Hostinger isn't enough — the change needs to spread to public name servers around the world. Until that happens, Brevo's verification will fail. dig tells you whether the rest of the internet can now see your new records.

💡 What is curl doing exactly?

curl is a command-line tool that makes web requests. The first call (PUT /authenticate) tells Brevo "go check my DNS now". The second call (GET /) reads back the current status. Brevo's checks are asynchronous — you ask, they go off and verify, you check back later for the result.

The BREVO_API_KEY in your env file is what proves the request is from you. Without it, Brevo wouldn't let just anyone trigger verifications on your account. The key is loaded into a shell variable so it never appears in your terminal history.

💡 Why change the From address?

Until now, the worker has been sending from business@360degreelogicalmktg.com — the one specific email Brevo verified for us at the very beginning of this whole journey (the "single sender" step). That worked, but it was a workaround.

With the whole domain now authenticated, any local-part on the domain works. Pick something cleaner and more purpose-fit — no-reply@, notifications@, recce@, whatever. This looks more professional in your client's inbox.

💡 Why this is genuinely zero-risk

This whole process only adds new outgoing-email permissions on top of your existing setup. We never edit the records that handle incoming mail or website traffic. Even if every DNS change you make ends up wrong, the worst case is: outgoing emails from the Recce Portal don't deliver until you fix or remove the bad records. Your customer Gmail keeps working. Your website keeps working. Your team's email keeps working.