DNS & Email Infrastructure Automation (Cloudflare + Zoho + GCP)
SEO page information
- Primary keyword
- DNS & Email Infrastructure Automation (Cloudflare + Zoho + GCP)
- Secondary keywords
- Cloud Engineering, Cloudflare API, Python, GCP Cloud Run, Certificate Manager, BigQuery
- Search intent
- A technical reader, recruiter, or prospective client looking for evidence of cloud engineering capability and the engineering choices behind DNS & Email Infrastructure Automation (Cloudflare + Zoho + GCP).
I built a fully automated DNS and email infrastructure provisioning tool that sets up production-ready DNS records, email authentication, and MX routing for a custom domain in under 5 minutes — replacing a tedious, error-prone manual process. This case study sets out the problem, implementation choices, controls, evidence boundaries, and next maturity steps behind the work.
Executive project snapshot
Updated 17 October 2026- Project type
- Cloud engineering
- My role
- Technical design and implementation owner
- Organisation or context
- Portfolio case study; confidential details are generalised where necessary
- Project duration
- Documented 2024
- Primary objective
- I built a fully automated DNS and email infrastructure provisioning tool — setting up production-ready DNS records, SPF, DKIM, DMARC, and MX routing for a custom domain in under 5 minutes via the Cloudflare and GCP APIs.
- Core technologies
- Cloudflare API, Python, GCP Cloud Run, Certificate Manager, BigQuery, Zoho Mail
- Key result
- The published record documents the implemented architecture, the core controls, and the technology choices that can be reviewed without exposing confidential operational data.
- Project status
- Documented implementation
- Evidence
- Portfolio implementation notes
The Problem and Why It Mattered
I built a fully automated DNS and email infrastructure provisioning tool — setting up production-ready DNS records, SPF, DKIM, DMARC, and MX routing for a custom domain in under 5 minutes via the Cloudflare and GCP APIs. The relevant technical and business risk is the cost of leaving this workflow, control, or product boundary unclear, manual, insecure, or difficult to operate. The case study focuses on the decisions used to make that risk manageable.
Objectives and Success Criteria
- Deliver the capability described in the project objective using a maintainable technical design.
- Make the main workflow, control boundary, and operational responsibilities explicit.
- Produce reviewable implementation evidence without publishing confidential values or customer data.
Requirements and Constraints
The implementation had to be reproducible, observable, and safe to describe publicly without exposing operational secrets or private infrastructure detail.
My Role and Ownership
I owned the technical design and implementation described in this portfolio record, including the technology choices, core system boundaries, and the documentation of the resulting approach. Related organisational decisions, vendor operations, and formal certification decisions remain outside the scope of this technical case study unless stated explicitly.
Solution Overview
The solution is built around Cloudflare API, Python, GCP Cloud Run. Its implementation is organised as the components below so that the architecture, control points, and operating model can be evaluated separately rather than treated as a list of tools.
Architecture and System Design
The public architecture description follows the path from the initiating user, workload, or operator action through the relevant cloud engineering components. Access boundaries, data or state handling, and operational controls are described at a safe level; secrets, private addresses, and client-sensitive implementation details are intentionally omitted.
Technology Decisions and Trade-Offs
I selected Cloudflare API, Python, GCP Cloud Run because they support the project objective and make the critical engineering boundaries explicit. The trade-off is operational and platform complexity: the design depends on documented configuration, controlled access, and ongoing review rather than assuming that a managed service or framework removes engineering responsibility.
Implementation Walkthrough
The following implementation notes describe the components that matter most to the project outcome. They are intentionally focused on technical decisions and operating behaviour instead of reproducing entire source files or sensitive configuration.
Implementation: DNS Provisioning Automation
Python script takes a domain name and Zoho Mail organisation identifier and creates via the Cloudflare API: MX records, SPF TXT (v=spf1 include:zoho.com ~all), DKIM TXT records (fetched from Zoho's API), DMARC TXT, CAA records restricting certificate issuance to trusted CAs.
Implementation: Cloud Run Deployment Integration
For domains hosting Cloud Run apps, the tool additionally creates DNS records pointing to the Cloud Run load balancer IP, adds the domain mapping via the GCP API, and triggers Certificate Manager to provision a TLS certificate.
Implementation: Propagation Verification
After records are created, the tool polls DNS resolvers in Lagos, London, New York, and Singapore every 30 seconds, reporting propagation status per region. Waits for full global propagation before reporting success.
Implementation: DMARC Reporting & Compliance Dashboard
Configures a DMARC reporting email address. A Cloud Function parses incoming DMARC aggregate reports, stores parsed results in BigQuery, and surfaces a weekly DMARC compliance dashboard.
Challenges, Failures and Corrections
This portfolio record does not invent deployment failures, client incidents, or corrective actions that are not supported by the published project evidence. Where operational details are confidential or were not captured for public release, the case study documents the design boundary and lesson instead of presenting an unsupported narrative.
Security, Compliance and Risk
The public record avoids secrets, customer data, and private infrastructure details. The relevant security controls, access boundaries, and operational risks are addressed in the implementation notes where they are material to the project.
Testing, Validation and Evidence
The evidence published for this project is the documented implementation, its stated architecture and controls, and the portfolio record. The published record documents the implemented architecture, the core controls, and the technology choices that can be reviewed without exposing confidential operational data. Claims are limited to the implementation details and outcomes documented in this case study.
Results and Evidence
The published record documents the implemented architecture, the core controls, and the technology choices that can be reviewed without exposing confidential operational data.
What I Learned
This project reinforced that cloud engineering work is not a technology checklist. The durable value comes from making boundaries, trade-offs, ownership, and evidence clear enough for another engineer or stakeholder to review and operate the system responsibly.
What I Would Improve Next
- Expand automated validation around the most important workflow and control boundaries.
- Add or deepen operational evidence, such as dashboards, test artefacts, or an architecture diagram where it is safe to publish one.
- Review the design against the next expected scale, reliability, and governance requirement before extending the system.
Final Takeaway
This cloud engineering case study addresses a defined technical problem through Cloudflare API, Python, GCP Cloud Run. It demonstrates my ability to turn requirements into an explainable design, implement the important controls, and document outcomes and limitations without overstating what the evidence proves.
Technologies
Discuss this project
If your team is facing a similar cloud, product, delivery, or compliance challenge, I’m available to discuss the current environment and a practical next step.
Contact Abraham